Re: my last attempt at sanity with namespaces

From: 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? Greg
Issue 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      Namespace
Question 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. :)

« previous php.internals (#41219) next »