Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31825
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error)
Message-ID: <46CBCDC7.1040001@lerdorf.com>
Date: Tue, 21 Aug 2007 22:46:47 -0700
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: Guilherme Blanco <guilhermeblanco@gmail.com>
CC: Stanislav Malyshev <stas@zend.com>, Marcus Boerger <helly@php.net>,
        internals Mailing List <internals@lists.php.net>
References: <46C9F217.8040804@chiaraquartet.net>	 <000001c7e3cb$9a80b160$6e02a8c0@thinkpad>	 <1925889548.20070821122333@marcus-boerger.de>	 <46CB1E05.4090100@zend.com> <bcb7aa500708211206i9a7b29cp5a330add726e28cd@mail.gmail.com>
In-Reply-To: <bcb7aa500708211206i9a7b29cp5a330add726e28cd@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH] allowing multiple namespaces per file plus
 namespaces with brackets
From: rasmus@lerdorf.com (Rasmus Lerdorf)

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