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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
