Download the PHP package jeremeamia/superclosure without Composer
On this page you can find all versions of the php package jeremeamia/superclosure. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download jeremeamia/superclosure
More information about jeremeamia/superclosure
Files in jeremeamia/superclosure
Package superclosure
Short Description Serialize Closure objects, including their context and binding
License MIT
Homepage https://github.com/jeremeamia/super_closure
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package superclosure
PHP SuperClosure
A PHP Library for serializing closures and anonymous functions.
No Longer Maintained
This software is no longer maintained. Consider using opis/closure instead.
The rest of the README will remain intact as it was prior to the software being abandoned.
Introduction
Once upon a time, I tried to serialize a PHP Closure object. As you can
probably guess, it doesn't work at all. In fact, you get a very specific error
message from the PHP Runtime:
Uncaught exception 'Exception' with message 'Serialization of 'Closure' is not allowed'
Even though serializing closures is "not allowed" by PHP, the SuperClosure library makes it possible. Here's the way you use it:
Yep, pretty cool, right?
Features
SuperClosure comes with two different Closure Analyzers, which each support
different features regarding the serialization of closures. The TokenAnalyzer
is not as robust as the AstAnalyzer, but it is around 20-25 times faster. Using
the table below, and keeping in mind what your closure's code looks like, you
should choose the fastest analyzer that supports the features you need.
| Supported Features | Via AstAnalyzer |
Via TokenAnalyzer |
|---|---|---|
Regular closures (anonymous functions)$fn = function (...) {...};
|
Yes | Yes |
Closures with context$fn = function () use ($a, $b, ...) {...};
|
Yes | Yes |
Recursive closures$fn = function () use (&$fn, ...) {...};
|
Yes | Yes |
Closures bound to an object$fn = function () {$this->something(); ...};
|
Yes | Yes |
Closures scoped to an object$fn = function () {self::something(); ...};
|
Yes | Yes |
Static closures (i.e, preserves the `static`-ness)$fn = static function () {...};
|
Yes | -- |
Closures with class name in params$fn = function (Foo $foo) {...};
|
Yes | -- |
Closures with class name in body$fn = function () {$foo = new Foo; ...};
|
Yes | -- |
Closures with magic constants$fn = function () {$file = __FILE__; ...};
|
Yes | -- |
| Performance | Slow | Fast |
Caveats
- For any variables used by reference (e.g.,
function () use (&$vars, &$like, &$these) {…}), the references are not maintained after serialization. The only exception to this is recursive closure references. - If you have two closures defined on a single line (why would you do this anyway?), you will not be able to serialize either one since it is ambiguous which closure's code should be parsed (they are anonymous functions after all).
- Warning: The
eval()function is required to unserialize the closure. This function is considered dangerous by many, so you will have to evaluate what precautions you may need to take when using this library. You should only unserialize closures retrieved from a trusted source, otherwise you are opening yourself up to code injection attacks. It is a good idea sign serialized closures if you plan on storing or transporting them. Read the Signing Closures section below for details on how to do this. - Cannot serialize closures that are defined within
eval()'d code. This includes re-serializing a closure that has been unserialized.
Analyzers
You can choose the analyzer you want to use when you instantiate the
Serializer. If you do not specify one, the AstAnalyzer is used by default,
since it has the most capabilities.
Analyzers are also useful on their own if you are just looking to do some
introspection on a Closure object. Check out what is returned when using the
AstAnalyzer:
Signing Closures
Version 2.1+ of SuperClosure allows you to specify a signing key, when you instantiate the Serializer. Doing this will configure your Serializer to sign any closures you serialize and verify the signatures of any closures you unserialize. Doing this can help protect you from code injection attacks that could potentially happen if someone tampered with a serialized closure. Remember to keep your signing key secret.
Installation
To install the Super Closure library in your project using Composer, simply require the project with Composer:
You may of course manually update your require block if you so choose:
Please visit the Composer homepage for more information about how to use Composer.
Why would I need to serialize a closure?
Well, since you are here looking at this README, you may already have a use case in mind. Even though this concept began as an experiment, there have been some use cases that have come up in the wild.
For example, in a video about Laravel and IronMQ by UserScape, at about the 7:50 mark they show how you can push a closure onto a queue as a job so that it can be executed by a worker. This is nice because you do not have to create a whole class for a job that might be really simple.
Or... you might have a dependency injection container or router object that is built by writing closures. If you wanted to cache that, you would need to be able to serialize it.
In general, however, serializing closures should probably be avoided.
Tell me about how this project started
It all started back in the beginning of 2010 when PHP 5.3 was starting to gain traction. I set out to prove that serializing a closure could be done, despite that PHP wouldn't let me do it. I wrote a blog post called Extending PHP 5.3 Closures with Serialization and Reflection on my former employers' blog, HTMList, showing how it could be done. I also released the code on GitHub.
Since then, I've made a few iterations on the code, and the most recent iterations have been more robust, thanks to the usage of the fabulous nikic/php-parser library.
Who is using SuperClosure?
- Laravel - Serializes a closure to potentially push onto a job queue.
- HTTP Mock for PHP - Serialize a closure to send to remote server within a test workflow.
- Jumper - Serialize a closure to run on remote host via SSH.
- nicmart/Benchmark - Uses the
ClosureParserto display a benchmarked Closure's code. - florianv/business - Serializes special days to store business days definitions.
- zumba/json-serializer - Serializes PHP variables into JSON format.
- PHP-DI - Compiles closure definitions into optimized PHP code.
- Please let me know if and how your project uses Super Closure.
Alternatives
This year the Opis Closure library has been introduced, that also provides the ability to serialize a closure. You should check it out as well and see which one suits your needs the best.
If you wish to export your closures as executable PHP code instead, you can check out the brick/varexporter library.
All versions of superclosure with dependencies
nikic/php-parser Version ^1.2|^2.0|^3.0|^4.0
symfony/polyfill-php56 Version ^1.0