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. Which suggestion are you trying to
debunk?
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
1) ever use short names inside a namespace declaration for any class in
the same namespace not defined in the same file
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
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
