+1 #3 On Fri, Oct 17, 2008 at 9:35 AM, Ryan Panning <[EMAIL PROTECTED]> wrote:
> 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 > >
