Comments on: Extending PHP 5.3 Closures with Serialization and Reflection http://www.htmlist.com/development/extending-php-5-3-closures-with-serialization-and-reflection/ A Web Development Blog by Synapse Studios Sun, 05 Feb 2012 02:47:42 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Jeremy Lindblom http://www.htmlist.com/development/extending-php-5-3-closures-with-serialization-and-reflection/comment-page-1/#comment-1090 Jeremy Lindblom Wed, 18 Jan 2012 19:42:46 +0000 http://www.htmlist.com/?p=551#comment-1090 Eric, Thanks for the feedback. You raise some good points about caching that I would like to look into. I realize that there are limitations to my approach, which is why I have never recommended using my class (or even the concept) in a production environment. It is not exactly a practical piece of code, it's more exploratory. You should check out my newer version in a github branch: https://github.com/jeremeamia/super_closure/tree/develop. This one does a better job at parsing the code (using php lexical tokenizer) such that the "source file formatting" problems you mentioned are not an issue. Not exactly a performance increase, but definitely more stable. Eric,

Thanks for the feedback. You raise some good points about caching that I would like to look into. I realize that there are limitations to my approach, which is why I have never recommended using my class (or even the concept) in a production environment. It is not exactly a practical piece of code, it’s more exploratory.

You should check out my newer version in a github branch: https://github.com/jeremeamia/super_closure/tree/develop. This one does a better job at parsing the code (using php lexical tokenizer) such that the “source file formatting” problems you mentioned are not an issue. Not exactly a performance increase, but definitely more stable.

]]> By: Eric Stevens http://www.htmlist.com/development/extending-php-5-3-closures-with-serialization-and-reflection/comment-page-1/#comment-1088 Eric Stevens Wed, 11 Jan 2012 16:40:56 +0000 http://www.htmlist.com/?p=551#comment-1088 Sorry to double-post, but it occurs to me that you could use a combination of private static properties on the object, and and spl_object_hash() to determine whether two Closures being serialized are instances of the same original Closure or not, and reuse the previously deserialized method if so. You'll have a hard time restoring correct scopes for the use() variables, but at least you can save yourself the overhead of repeated interpreter spinups, as well as reduce the memory footprint in the process. Sorry to double-post, but it occurs to me that you could use a combination of private static properties on the object, and and spl_object_hash() to determine whether two Closures being serialized are instances of the same original Closure or not, and reuse the previously deserialized method if so. You’ll have a hard time restoring correct scopes for the use() variables, but at least you can save yourself the overhead of repeated interpreter spinups, as well as reduce the memory footprint in the process.

]]> By: Eric Stevens http://www.htmlist.com/development/extending-php-5-3-closures-with-serialization-and-reflection/comment-page-1/#comment-1087 Eric Stevens Wed, 11 Jan 2012 16:36:12 +0000 http://www.htmlist.com/?p=551#comment-1087 Too bad this has to rely on eval() to work correctly. But I'm not sure there's an alternative, really. In an environment which takes advantage of PHP Opcode Cache (such as relying on extensions like APC) - which any production environment should be - this will come with a substantial performance penalty. eval() spins up the PHP interpreter, and it will have to be spun up for every deserialized function. It also means multiple instances of the same closure will each use their own memory (rather than sharing memory as they would in their original instantiation), both in terms of their use() parameters and their actual executable opcode. It's also a little fragile with respect to source file formatting, the original Closure function needs to be on lines of its own, with no surrounding markup bleeding over. Still, it's clever, and to the best of my knowledge there is not a better way to accomplish serializing a Closure. Even opcode caching doesn't provide a path to this end without using a separate intermediary file (defeating the point of serialization). Too bad this has to rely on eval() to work correctly. But I’m not sure there’s an alternative, really. In an environment which takes advantage of PHP Opcode Cache (such as relying on extensions like APC) – which any production environment should be – this will come with a substantial performance penalty. eval() spins up the PHP interpreter, and it will have to be spun up for every deserialized function.

It also means multiple instances of the same closure will each use their own memory (rather than sharing memory as they would in their original instantiation), both in terms of their use() parameters and their actual executable opcode.

It’s also a little fragile with respect to source file formatting, the original Closure function needs to be on lines of its own, with no surrounding markup bleeding over.

Still, it’s clever, and to the best of my knowledge there is not a better way to accomplish serializing a Closure. Even opcode caching doesn’t provide a path to this end without using a separate intermediary file (defeating the point of serialization).

]]> By: PHP APC Tutorial – cz.3: User Variable Cache – Czyli optymalizacja skryptów PHP | Opolski Portal Programistyczny http://www.htmlist.com/development/extending-php-5-3-closures-with-serialization-and-reflection/comment-page-1/#comment-1009 PHP APC Tutorial – cz.3: User Variable Cache – Czyli optymalizacja skryptów PHP | Opolski Portal Programistyczny Sat, 26 Nov 2011 12:32:50 +0000 http://www.htmlist.com/?p=551#comment-1009 [...] należy zastosować specjalną klasę opisaną przez Pana co się zowie Jeremy Lindblom opisaną tutaj, a dostępną do ściągnięcia tutaj. Wtedy można tego dokonać w następujący [...] [...] należy zastosować specjalną klasę opisaną przez Pana co się zowie Jeremy Lindblom opisaną tutaj, a dostępną do ściągnięcia tutaj. Wtedy można tego dokonać w następujący [...]

]]> By: Erin http://www.htmlist.com/development/extending-php-5-3-closures-with-serialization-and-reflection/comment-page-1/#comment-968 Erin Thu, 27 Oct 2011 03:27:10 +0000 http://www.htmlist.com/?p=551#comment-968 Awesome piece of code, even if it is a little sad that closures can't be natively serialized. It does make some sense I suppose given that pass-by-reference would be impossible. It would be really cool if you could throw an exception when attempting to serialize a closure that *does* have pass-by-reference parameters. I have an idea for something really cool that can be achieved using this. I'll keep you posted if I can pull it off ;) Awesome piece of code, even if it is a little sad that closures can’t be natively serialized. It does make some sense I suppose given that pass-by-reference would be impossible.

It would be really cool if you could throw an exception when attempting to serialize a closure that *does* have pass-by-reference parameters.

I have an idea for something really cool that can be achieved using this. I’ll keep you posted if I can pull it off ;)

]]> By: Tyron http://www.htmlist.com/development/extending-php-5-3-closures-with-serialization-and-reflection/comment-page-1/#comment-897 Tyron Thu, 12 May 2011 20:37:20 +0000 http://www.htmlist.com/?p=551#comment-897 Sweet, thanks for this piece of code! Sweet, thanks for this piece of code!

]]> By: AzPHP User's Group » Blog Archive » PHP Object Oriented Programming Reinvented and Serializing Closures http://www.htmlist.com/development/extending-php-5-3-closures-with-serialization-and-reflection/comment-page-1/#comment-693 AzPHP User's Group » Blog Archive » PHP Object Oriented Programming Reinvented and Serializing Closures Wed, 29 Sep 2010 18:00:46 +0000 http://www.htmlist.com/?p=551#comment-693 [...] http://www.htmlist.com/development/extending-php-5-3-closures-with-serialization-and-reflection/ [...] [...] http://www.htmlist.com/development/extending-php-5-3-closures-with-serialization-and-reflection/ [...]

]]> By: Eric Muyser http://www.htmlist.com/development/extending-php-5-3-closures-with-serialization-and-reflection/comment-page-1/#comment-575 Eric Muyser Tue, 25 May 2010 03:32:49 +0000 http://www.htmlist.com/?p=551#comment-575 Ah right right right. "same request" is the difference. I'm using this in context of a cron trying to IPC with an FFMPEG service. Lambdas are the key, otherwise it's simply too messy imo. It's easy to just store an ID somewhere for later, like it does now, but your article was a good direction towards abstracting it. So you're serializing it in an HTTP request for a different request. Very cool :] I'm going to keep an eye out for when I might need such functionality. Ah right right right. “same request” is the difference. I’m using this in context of a cron trying to IPC with an FFMPEG service. Lambdas are the key, otherwise it’s simply too messy imo. It’s easy to just store an ID somewhere for later, like it does now, but your article was a good direction towards abstracting it. So you’re serializing it in an HTTP request for a different request. Very cool :] I’m going to keep an eye out for when I might need such functionality.

]]> By: Jeremy Lindblom http://www.htmlist.com/development/extending-php-5-3-closures-with-serialization-and-reflection/comment-page-1/#comment-574 Jeremy Lindblom Mon, 24 May 2010 18:19:27 +0000 http://www.htmlist.com/?p=551#comment-574 Thanks Eric. My script is geared towards serializing the Closure across multiple requests, so preserving the variables passed-by-reference is not really a concern, because the references are lost once the request ends. I'm pretty sure there's nothing that can be done about that. I'm not entirely sure why I would want to serialize and unserialize the closure in the same request anyway. (And yes, I'm aware of code hinting, I just opted for the Exception in this example.) Thanks Eric. My script is geared towards serializing the Closure across multiple requests, so preserving the variables passed-by-reference is not really a concern, because the references are lost once the request ends. I’m pretty sure there’s nothing that can be done about that. I’m not entirely sure why I would want to serialize and unserialize the closure in the same request anyway. (And yes, I’m aware of code hinting, I just opted for the Exception in this example.)

]]> By: Eric Muyser http://www.htmlist.com/development/extending-php-5-3-closures-with-serialization-and-reflection/comment-page-1/#comment-573 Eric Muyser Sun, 23 May 2010 16:18:48 +0000 http://www.htmlist.com/?p=551#comment-573 I actually went a different way with yours as inspiration. Not sure though (haven't tested much). http://eric.muyser.com/php-class-lambda/ Thoughts? BTW PHP has code hinting (your line #10) I actually went a different way with yours as inspiration. Not sure though (haven’t tested much).

http://eric.muyser.com/php-class-lambda/

Thoughts? BTW PHP has code hinting (your line #10)

]]>