Re: solving the namespace conflict issues between function/staticmethod class constant/ns constant

Dmitry Stogov schreef:

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's unfair to call it inconsistent, the syntax is consistent in it's own right and uses an operator which is known to mean 'member' in a pre-existing context. if it truly can be considered inconsistent then that is only because Greg proposal avoids BC breakage, inconsistency was inherent because two different operators were chosen for class scope operator ('->' and '::') which your following comment demonstrates is technically unnecessary.

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.

Yes. Changing :: into any other separator solves the functions/static methods and constants ambiguity, but it also breaks intuitive syntax.

a, it doesn't actually solve all the ambiguity issues, Greg has tried to point this out. I actually hammered Greg a number of times about the :: seperator and the fact that changing it fixes the ambiguities ... after careful consideration he came back to me and pointed out that *most* of the ambiguities are resolved but not all, simply because (for one) it's still not possible to distinguish between an aliased namespace and an aliases namespace name. b, the presumption that the current syntax is intuitive is completely subjective. imho it's not intuitive specifically because it's open to intepretation as to what code refers to (aka ambiguous).

Thanks. Dmitry.

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. regards, Lukas Kahwe Smith mls@pooteeweet.org