Matthew Kavanagh wrote:
> Rasmus Lerdorf wrote:
>> Stanislav Malyshev wrote:
>>
>>> Compile-time resolution means you don't get performance penalty for
>>> namespaces when you are not using it, and have very low costs when you
>>> do use it. Allowing blanket imports means we don't know what "new Foo()"
>>> means until it is executed - meaning we need to make extra lookups on
>>> each class fetch, even if the code doesn't use namespaces at all. That's
>>> only one problem with blanket imports.
>>>
>>
>> And a fatal one in my book. For the folks arguing so passionately about
>> this namespace implementation, try to consider the compiler vs. executor
>> issues involved. We really need to stop the trend of pushing everything
>> down into the executor.
>>
>> -Rasmus
>>
>>
> The compile time vs. execution time argument may be a good one against
> global import and against other crazy ideas in my head (like allowing
> statements in namespaces).
>
> But why not allow importing namespaced functions and constants into the
> global namespace?
>
> If this were added then "blanket import" could be left to the intrepid
> and foolhardy programmer to do manually. It'd just end up being
> boilerplate and if someone really objects to some extra lines they could
> add an explicit fold in their editor to hide it.
As long as it doesn't go into the global namespace directly. As in:
namespace foo;
class bar1 {
...
}
class bar2 {
...
}
import foo:* as myfoo
gives you:
myfoo:bar1 and myfoo:bar2
and not bar1 and bar2 directly in the global namespace. The latter is a
performance killer across the board but I see no issue with the former.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
