Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40607
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain iamjochem.com from 194.109.193.121 cause and error)
Message-ID: <48D7F154.6040103@iamjochem.com>
Date: Mon, 22 Sep 2008 21:26:12 +0200
User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707)
MIME-Version: 1.0
To: Dmitry Stogov <dmitry@zend.com>
CC: Lukas Kahwe Smith <mls@pooteeweet.org>, 
 Gregory Beaver <greg@chiaraquartet.net>,
 internals@lists.php.net
References: <48D47532.8080102@chiaraquartet.net> <e666c3890809200924t28f1c585kad77729dd608c5ad@mail.gmail.com> <10845a340809201643q59e27211i471e09241f7253b1@mail.gmail.com> <200809202000.38870.larry@garfieldtech.com> <E5.0A.65213.536E5D84@pb1.pair.com> <48D66160.40306@chiaraquartet.net> <48D79672.4060208@zend.com> <48D7A51C.9030805@chiaraquartet.net> <48D7ADAE.5030500@zend.com> <35BF242A-A479-4C8D-9137-0ED1B68109FE@pooteeweet.org> <48D7C2AE.6000707@zend.com>
In-Reply-To: <48D7C2AE.6000707@zend.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] solving the namespace conflict issues between function/staticmethod
 class constant/ns constant
From: jochem@iamjochem.com (Jochem Maas)

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
>>
>>
>>
>