Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40600
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.163 as permitted sender)
Message-ID: <48D7ADAE.5030500@zend.com>
Date: Mon, 22 Sep 2008 18:37:34 +0400
User-Agent: Thunderbird 2.0.0.16 (X11/20080723)
MIME-Version: 1.0
To: Gregory Beaver <greg@chiaraquartet.net>
CC: 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>
In-Reply-To: <48D7A51C.9030805@chiaraquartet.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] solving the namespace conflict issues between function/staticmethod
 class constant/ns constant
From: dmitry@zend.com (Dmitry Stogov)



Gregory Beaver wrote:
> Dmitry Stogov wrote:
>> Hi Greg,
>>
>> Greg Beaver wrote:
>>   
>>> Lupus Michaelis wrote:
>>>     
>>>> Larry Garfield a écrit :
>>>>
>>>>       
>>>>> I agree that #5 seems like the best solution.  The problem is caused
>>>>> by the double meaning of ::.  All of the other solutions feel like
>>>>> bandaids.  
>>>>>         
>>>>   They are not a double meaning : it is a scope resolver. Like in C++.
>>>> So please all stop this war about namespaces, and look where it was
>>>> resolved in other languages. It will be wisely :)
>>>>       
>>> Hi,
>>>
>>> Amazingly enough, this work has already been done.  The first thing
>>> noticed is that C++ is a compiling language, and PHP isn't.  Therefore
>>> at compile time, it is possible to know every single file that will be
>>> available, every single class, and so on.  This enables all kinds of
>>> clever resolution such as importing ns::* and it actually works with
>>> full performance.
>>>
>>> PHP, on the other hand, is a dynamic language, and it is impossible to
>>> know in advance which files, which classes, which namespaces will be
>>> defined.  Other dynamic languages that have implemented namespaces have
>>> solved the problems mentioned via run-time resolution, which is much slower.
>>>
>>> One key difference from C++ is that namespaces do *not* define scope in
>>> PHP.  The only constructs that define scope different from global scope
>>> are functions and now closures (as I understand them from reading the
>>> mailing list).
>>>
>>> I suppose I should have mentioned option #6: do all class, function and
>>> constant resolution at run-time, "obsoleting" all opcode caches and make
>>> PHP 5.3 an unusable release for any high traffic websites.
>>>     
>> Please check your suggestions before publishing them.
>>
>> <?php
>> class Foo {
>>         function bar() {
>>         }
>> }
>>
>> function simplecall() {
>>   for ($i = 0; $i < 1000000; $i++) {
>>       Foo::bar();
>>       Foo::bar();
>>       Foo::bar();
>>       Foo::bar();
>>       Foo::bar();
>>       Foo::bar();
>>       Foo::bar();
>>       Foo::bar();
>>       Foo::bar();
>>       Foo::bar();
>>   }
>> }
>>
>> simplecall();
>> ?>
> 
> <snip>
> 
> hi Dmitry,
> 
> Let me quote myself from right above your reply:
> 
> "option #6: do all class, function and constant resolution at run-time"
> 
> This would be slow and eliminate most of the benefit of opcode caches. 
> The script you posted does not demonstrate option #6 because that's not
> how PHP works or has ever worked.

The script I posted calls static methods and does two cache lookups in
5.3 because of runtime resolution. However it does quick cache lookups
without cache-value calculating. As you can see they work faster then
single hash lookup in 5.2.

>  Which suggestion are you trying to debunk?

Sorry, I probably misunderstood you, I thought you had talked about
speed of current implementation. Anyway, php resolves names at run-time now.

> I was never saying the current implementation is slow, only that it is
> broken.  Without changes, it is dangerous in PHP's namespace
> implementation to

I wouldn't say it broken, I would say it has some ambiguity problems.

> 1) ever use short names inside a namespace declaration for any class in
> the same namespace not defined in the same file

why is it dangerous?

> 2) mix functions and classes in the same project with hierarchical
> namespace declarations, or mix namespace constants with class constants
> 
> #1 makes namespaces essentially more verbose than the existing situation
> (:: is longer than _), and #2 requires users to perform more diligence
> than they would have to before namespaces.  In both cases, this either
> introduces more chance for subtle logic failure compared to PHP prior to
> namespaces, or requires longer class names.  I highly doubt that is the
> intention.
> 
> 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

Thanks. Dmitry.