Re: solving the namespace conflict issues between function/staticmethod class constant/ns constant
| From: | Larry Garfield | Date: | Tue, 23 Sep 2008 03:59:24 +0000 |
| Subject: | Re: solving the namespace conflict issues between function/staticmethod class constant/ns constant | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-40614@lists.php.net to get a copy of this message | ||
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
larry@garfieldtech.com