Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40596
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: <48D79672.4060208@zend.com>
Date: Mon, 22 Sep 2008 16:58:26 +0400
User-Agent: Thunderbird 2.0.0.16 (X11/20080723)
MIME-Version: 1.0
To: Greg Beaver <greg@chiaraquartet.net>
CC: Lupus Michaelis <mickael+php@lupusmic.org>, 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>
In-Reply-To: <48D66160.40306@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)

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();
?>

$ time php5.2/CGI-RELEASE/sapi/cli/php -n bench.php

real    0m7.458s
user    0m7.416s
sys     0m0.007s

$ time php5.3/CGI-RELEASE/sapi/cli/php -n bench.php

real    0m7.337s
user    0m7.252s
sys     0m0.002s


As you can see 5.3 is faster.
Of course it could be faster, but it's a winer anyway :)

I really don't see a reason to change namespace syntax into a less
intuitive way. Your speed degradation argument isn't truth. The
ambiguity problem exists, but it is just an ability to use php in a
wrong way. Just don't create conflicting names.

I would recommend option #1 (stay it as is + document)

Thanks. Dmitry.