Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31811
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 38.99.98.18 cause and error)
Message-ID: <46CB40E8.7050602@chiaraquartet.net>
Date: Tue, 21 Aug 2007 14:45:44 -0500
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: Rasmus Lerdorf <rasmus@lerdorf.com>
CC: internals Mailing List <internals@lists.php.net>
References: <46C9F217.8040804@chiaraquartet.net> <b5f7bf6c0708201306id6ae99i5bf821f9d273be85@mail.gmail.com> <46C9F50A.7040009@sci.fi> <46CA6367.9090301@lerdorf.com> <46CA71F4.40205@chiaraquartet.net> <46CA75ED.8060506@lerdorf.com> <46CA7999.8020605@chiaraquartet.net> <46CA7CC5.3080803@lerdorf.com>
In-Reply-To: <46CA7CC5.3080803@lerdorf.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH] allowing multiple namespaces per file plus
 namespaces with brackets
From: greg@chiaraquartet.net (Gregory Beaver)

Rasmus Lerdorf wrote:
> Well, outside of an opcode cache, you wouldn't care whether the logic is
> in the compiler or the executor.  But once you introduce an opcode
> cache, anything that you can resolve at compile-time means one less
> thing to do at execute time which means that the feature essentially
> becomes free once the file has been compiled and cached.
>
> Current opcode caches, including APC, will replace class and function
> definitions with NOPs in the cached op_arrays when it can definitively
> resolve them at compile-time.  Things like autoload and conditional
> includes are examples of features that destroy this optimization because
> we need the runtime context in order to determine what to do which means
> we have to do it in the executor.  Then of course there is the nightmare
> of class inheritance spanning includes and code that sometimes includes
> a file containing a child class conditionally and other times
> unconditionally.  That caused us weeks, if not months, of headache in
> APC land.
>   
Hi,

I remember this anguish, and have been following closely APC development
through Gopal's blog, watching commit messages and so on, and have been
proposing changes to PEAR2 (admittedly extremely controversial ones)
that would make it more APC-friendly, so the last thing I want to do is
add headaches in APC land, quite the opposite.
>> I don't wish to cause trouble on these points, but I don't yet
>> understand how the patch makes things any worse for APC, as all of the
>> namespacing is still 100% deterministic and is a closed per-file system
>> done at compile-time.
>>     
>
> Perhaps it doesn't.  What worries me is the ability to change the
> namespace mid-file.  Maybe I can resolve this entirely at compile-time
> as long as no includes, imports or any other tricks can be used to break
> the namespace-to-one-file association.  And we especially have to avoid
> anything that would cause a single file to change namespaces depending
> on how it is included and where it is included from.
I understand this.

I guess the way I would answer this is to question how you think APC
would react differently to these two examples:

example 1:
file1.php:
<?php
namespace gronk;
class bar {}
?>

another.php:
<?php
namespace another;
class boo {}
?>

file2.php:
<?php
namespace foo;
include 'file1.php';
include 'another.php';
import gronk::bar;
class extender extends bar {}
?>

====

example 2:
file1.php:
<?php
namespace gronk;
class bar {}
?>

file2.php:
<?php
include 'file1.php';
namespace another {
    class boo {}
}
import gronk::bar;
namespace foo {
    class extender extends bar {}
}
?>

The two are functionally equivalent ways of doing things, the first
without my patch, and the second with it.  Would the second example's
file2.php cause greater difficulty for APC in your estimation?

Greg