Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34227
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.net designates 213.165.64.20 as permitted sender)
Message-ID: <476DB8AD.3060608@gmx.net>
Date: Sun, 23 Dec 2007 02:23:57 +0100
User-Agent: Thunderbird 2.0.0.9 (X11/20071031)
MIME-Version: 1.0
To: php-dev List <internals@lists.php.net>
References: <98b8086f0712150818n40056cedyf0aae7a5a08a27b7@mail.gmail.com> <476582E6.7020808@zend.com> <D1011E25-76DB-4936-AF3B-F98F19DC2139@procata.com> <200712172130.08216.larry@garfieldtech.com> <4FADC266-873E-4FD2-BEC8-28EA9D833297@procata.com> <476D2854.5070803@gmx.net> <503D0384-1014-4CD1-BCAC-8F0950D5FC68@bitxtender.com>
In-Reply-To: <503D0384-1014-4CD1-BCAC-8F0950D5FC68@bitxtender.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] PATCH: Implementing closures in PHP
From: chris_se@gmx.net (Christian Seiler)

Hi!

I'm going to answer to everybody at once, if that's OK.

David Zülke wrote:

> One question about the names you generate for the function table in
> combination with opcode caches.
> [...]
> While this is a constructed example, it could easily occur with
> conditional includes with environments that use opcode caches.

Oh, yes, that's true, I didn't think of that, thanks a lot for pointing
that out!

Tomorrow I'll post an updated patch which will make sure this doesn't
happen (see below).

troels knak-nielsen wrote:

> I have another observation about names.
> Instead of using an arbitrary name, as the name of the function,
> wouldn't it be possible to let the name be derived from the
> function-body. Eg., if you took the function-body's tokens and created
> a hash from them. This would have two implications: 1) Multiple
> definitions of the same function would be optimised into one. And more
> importantly 2) , it would be possible to serialize/unserialize a
> closure. Of course, this won't work if an anonymous function is a
> resource, since resources can't be serialized. This would work for
> Wez' original patch though.

Thanks for the suggestions, and although I don't completely agree with
you, you pointed me into the direction I'm leaning towards now, so
thanks. :-)

First of all: I don't quite understand what you mean when you want to
serialize a function (closure or not)? The opcodes? Ok, sure, with the
current PHP implementation you can serialize the variable used to CALL
the function (e.g. with $func = 'str_replace'; $func is only a string
and can be serialized). But where would you need that? (Ok, for normal
functions that are named this could actually be useful, but for
anonymous functions?)

Using the function body itself as a hashed value for the function name
would require some _major_ changes to the parser. Currently, the
function name has to be known before the function body starts. Also, the
tokens inside the function would have to be tracked and stored in an
array somehow. This would be quite a performance penalty during compile
time.

But: The idea I hat thanks to you is to use the file name and a per-file
counter for the function name. So the name would be something like
(symbollically speaking) '__compiled_lambda_' + hashfunction(__FILE__) +
'_' + per_file_counter. That would solve the problem with opcode caches
while not causing any real performance penalties (the hash of the loaded
file would only have to be calculated once).

As I also wrote above, I'll post an updated patch tomorrow that will
address this problem.

Martin Alterisio wrote:

> That's very kind of you but, if I was explained right, you don't have
> copyright on a patch. [...]

I don't agree at all (except for the part where a patch is a derived
work) but since I don't want to talk about copyright laws here (no
offense, but I'd rather spend my time writing code), I think we both can
live with the following statement: If you're right, the PHP team can use
the patch anyway, so it isn't a problem. If I'm right, I've given the
PHP team the necessary permission to use it, so it isn't a problem either.

Regards,
Christian