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. :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
