Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40614
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.30.16 cause and error)
To: internals@lists.php.net
Date: Mon, 22 Sep 2008 22:59:24 -0500
User-Agent: KMail/1.9.9
References: <48D47532.8080102@chiaraquartet.net> <48D7ADAE.5030500@zend.com> <35BF242A-A479-4C8D-9137-0ED1B68109FE@pooteeweet.org>
In-Reply-To: <35BF242A-A479-4C8D-9137-0ED1B68109FE@pooteeweet.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <200809222259.24737.larry@garfieldtech.com>
Subject: Re: [PHP-DEV] solving the namespace conflict issues between function/staticmethod class constant/ns constant
From: larry@garfieldtech.com (Larry Garfield)

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