On Monday 22 September 2008 10:45:33 am Lukas Kahwe Smith wrote: > On 22.09.2008, at 16:37, Dmitry Stogov wrote: > >> Returning to the original debate, if you really believe this > >> conflict is > >> not an issue, then why was the first user note published last > >> December a > >> note about this conflict? > >> > >> http://us3.php.net/manual/en/language.namespaces.php#80035 > > > > I could add nothing. The problem exists, but proposed solution make > > language even worse. Having A::B->foo() and ->foo() or ::foo() and > > A::B->C::foo() is much more inconsistent from my point of view. > > It would be better to change static class separator from :: to ->, but > > it's a BC break > > Again, not speaking as an RM, I personally feel we really do have to > solve this ambiguity problem. I do not agree that this only affects > "namespace abusers". > > That being said we have to stay realistic. What Greg proposes is > realistic imho. Its essentially reusing an existing OO syntax. The > same is what we have today with the double colon. While I agree that > it would not be my natural choice, it seems it solves our real problem > of the frequently mentioned ambiguity problem. So from that perspetive > its a step forward from the current syntax. > > I know we are getting dangerously close (or are we already back in > it?) to the namespace separator discussion. I remember back then a lot > of people were saying lets get the implementation done first and then > worry about the syntax. I guess we are more or less at this point now.
I think we are already back in it, especially if we're talking about dropping functions from namespaces in order to preserve the operator. I don't find reusing a second symbol to be a step up, though. I can see it making it harder to read, not easier, to reuse *both* characters from object resolution in a different context. That just makes my brain hurt even more than reusing :: does. I'd argue there's nothing uniquely intuitive about :: as a namespace operator other than the current 5.3 alpha uses it. -- Larry Garfield [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
