Hello Rasmus,
the limitations given here and very good explained should imo stay. They
should because that is not only easier to understand and easier for anything
that has to deal with it like opcode caches and whatnot but also adhrers to
the good old KISS approach of PHP.
That said, instead of changing the current implementation every day we
should step back a bit and first find a consensus whether we want anything
more or even anything less than what we currently have.
My personal feeling is that we should stick to one name binding per file.
And we should do so without braces (if I want it complex I just take a more
complex language).
marcus
Wednesday, August 22, 2007, 7:46:47 AM, you wrote:
> Guilherme Blanco wrote:
>> I don't understand very well what Rasmus tried to mention with nested
>> namespaces and opcache, but seems there're a limitation and I am
>> interested to know which (if possible, try to explain in other
>> words)...
>> Why am I asking this? I am changing the Gregory's patch... now,
>> current_namespace holds a zval. I am changing it first to a stack, and
>> pushing and popping the namespaces based on block declaration.
> The reason Dmitry went with a package-like one-namespace per file
> approach was to avoid any confusion that might be caused by braces and a
> stack-like expectation. For example, when you have code like this:
> function foo() {
> include 'bar.inc';
> }
> Then everything in bar.inc becomes part of the foo() function. So, in a
> stack-based namespace implementation with braces you might have code
> like this:
> namespace foo {
> include 'bar.inc';
> }
> Now, if bar.inc defines functions or classes, one would logically expect
> these to be in the foo namespace. But this is exactly what we want to
> avoid. Imagine this code:
> include 'bar.inc';
> namespace foo {
> include 'bar.inc';
> }
> This is where everything starts getting complicated for an opcode cache
> because it would really like to resolve everything at compile-time. But
> in this case the functions and classes in bar.inc have different names
> depending on the context of the include. Opcode caches already have to
> deal with this to some extent in terms of conditional includes, but this
> would take it a step further, and the last thing we need is to make the
> opcode caches more complex and slow down the engine further by making
> every symbol more complex to resolve.
> I honestly don't have much use for namespaces and I couldn't care less
> what they are called, but I do care that they don't slow down code that
> doesn't use them, and even for code that does use them, I would hate to
> have another autoload-like performance penalty for what would otherwise
> be a useful feature in some cases.
> -Rasmus
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
