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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
