Re: my last attempt at sanity with namespaces
| From: | Ryan Panning | Date: | Fri, 17 Oct 2008 14:35:37 +0000 |
| Subject: | Re: my last attempt at sanity with namespaces | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-41219@lists.php.net to get a copy of this message | ||
Greg Beaver wrote:
Hi, http://wiki.php.net/rfc/namespaceissues Read it and discuss. Let's be clear people: the technical problems in namespaces are limited and solvable. The problems in the political environment surrounding them may not be. Wouldn't politics be a stupid-ass reason to remove namespaces? GregIssue A: #2 Issue B: Yes The reason I like #2 is because it also helps with the autoload confusion. It will clearly state that you are either looking for a class or namespace file, by looking for the element separator. However, I think :> or something other than ::: would be a better separator, for better visability. Ex:
Request Autoload Gets Type-----------------------------------------------
A::B:>C A::B:>C Class A::B:>func() A::B Namespace A::B:>C::CONST A::B:>C Class A::B::C:>D::method() A::B::C:>D Class A::B::C::D:>CONST A::B::C::D NamespaceQuestion for issue B, will the change only effect class requests? Or would it also trigger autoload for function requests (thinking it's a namespace request)? I could see that being a problem as 90% of function requests are for internal functions and ::func() for everything would be a pain. Similar goes for namespace function/const requests. At this point it wouldn't be a big deal but lets say core internal functions are migrated to namespaces (ex: Array::map()). Does that trigger autoload before it finds the internal Array::map()? I'm thinking that's where option #3 comes into play, but "using .." every internal class/ns/func would also be a pain. Sorry if this was already answered, I've been trying to keep up. :)