php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #67569 Make Closures serializable
Submitted: 2014-07-04 10:24 UTC Modified: -
Votes:6
Avg. Score:3.8 ± 1.5
Reproduced:5 of 6 (83.3%)
Same Version:1 (20.0%)
Same OS:3 (60.0%)
From: tom at r dot je Assigned:
Status: Open Package: Class/Object related
PHP Version: 5.5.14 OS: *
Private report: No CVE-ID: None
View Developer Edit
 [2014-07-04 10:24 UTC] tom at r dot je 
Description:
------------
This seems like a very arbitrary restriction from the PHP Developers.

I don't know much about the internals of how they work, but serialzing variables used in the use() part is no different than storing instance variables inside objects so that shouldn't pose an issue.

The issue, I'm guessing, is the method body. As it's not in a file it cannot be loaded if the variables are serialized, but since a Closure object is an internal class, why can't PHP store the method body in the closure object itself as an instance variable? Then the Closure object could be serialized and when unserialized, essentially just eval the method body to restore it?


The closure class would then have a structure something like this:

class Closure {
	private $body;
	private $args = [];
	private $bodyText;
	
	public function __invoke(...$args) {
		$this->body(...$args);
	}
	
	public function __wakeUp() {
		$this->body = eval($this->bodyText);
	}	
}

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-01-27 23:37 UTC] jeremeamia at gmail dot com 
As the author of the SuperClosure library, which attempts to circumvent this problem in userland code, I understand your frustration. However, It is definitely a little more complicated that what you've described.

For the code part, yes, if PHP stored the code as a property, that would help. However, there are also things that might not work correctly when unserialized, like non fully-qualified class names and magic constants. These are determined by where the closure was instantiated. Unserializing effectively re-instantiates the closure in a new context, changing the values and, potentially, not understanding class references.

For the "use"d variables, you run into trouble when variables are used by reference or when they are resources or when they are also closures or when they are objects or arrays that contain nested closures.

Also, there is the closure binding and scope (e.g., what does $this, self, static, parent refer to) that would need to be preserved as well. That information is available, but it needs to be treated with care during both serialization and unserialization to preserve the original intentions.

So while I'd love to see serialization of both anonymous functions and classes, I understand the challenges behind it that make it difficult.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Apr 04 01:01:30 2025 UTC