Opis Closure 4.x is available for testing

Question

Opis Closure 4.x is available for testing

msarca opened this issue 5 years ago · 22 comments

Hi, everyone!

I'm happy to announce that we are about to launch a new version of Opis Closure.

This version targets PHP +7.4 and use FFI to make closures truly serializable, without wrapping them inside a SerializableClosure object. This means that you no longer need to adapt your library's logic in order to have serializable closures. One line of code and closures will become serializable.

Please give it a try and let us know if you have encountered any issues while testing.

Answer 1 · 2020-06-10T19:29:20.000Z

Version 4.0 does not work:
Serialization Closure is broken. $reflection->getCode() returns <?php and namespace ... sometimes

You can try to fix your bugs with running test in yiisoft/composer-config-plugin#82
Run tests: ./vendor/bin/phpunit --debug
See generated files in tests/Integration/Environment/vendor/yiisoft/composer-config-plugin-output/ (params.php or web.php).

Answer 2 · 2020-06-10T20:22:42.000Z

@xepozz If you believe you have discovered a bug, please open a new issue so we could treat it properly. Also, you must be aware that Opis Closure 4.x is incompatible with 3.x and generates the code differently than you might expect. Our goal is to make closures serializable. If you are using this library for different purposes, than it might not be the most appropriate tool.

Answer 3 · 2020-06-10T20:38:37.000Z

Just to be clear for everyone reading this thread: our public API consist of a single function Opis\Closure\init. Everything else is internal. Please use this library strictly for closure serialization/unserialization. If you want to analyse a closure's source code nikic/php-parser will help you do a better job.

Answer 4 · 2020-06-11T14:42:24.000Z

@xepozz If you believe you have discovered a bug, please open a new issue so we could treat it properly. Also, you must be aware that Opis Closure 4.x is incompatible with 3.x and generates the code differently than you might expect. Our goal is to make closures serializable. If you are using this library for different purposes, than it might not be the most appropriate tool.

We are using this package for serializing/unserializing standalone closures and closures in a properties.

Answer 5 · 2020-06-11T15:24:36.000Z

@xepozz Please open a new issue and provide the most basic example that can be reproduced. Thanks.

Answer 6 · 2020-06-11T16:00:34.000Z

@xepozz I did take a look at your test results and the first thing that struck me was this: Error: Class 'Environment\Serializer\CustomSerializer' not found. Incidentally that is the class where closure serialization was supposed to be happen.

Answer 7 · 2020-06-14T17:21:41.000Z

@xepozz I did take a look at your test results and the first thing that struck me was this: Error: Class 'Environment\Serializer\CustomSerializer' not found. Incidentally that is the class where closure serialization was supposed to be happen.

I've fixed it

Answer 8 · 2020-07-02T10:53:41.000Z

We added PHP 8 support

Answer 9 · 2020-07-06T21:47:45.000Z

A huge feature of Laravel is queued Closures with proper ORM model serialization / deserialization when the models are part of the use portion of the Closure. We accomplished this in previous versions of Opis by overwriting methods that I had PR'd to Opis...

My original PR to Opis: #21

Our overwritten methods can be seen here: https://github.com/illuminate/queue/blob/master/SerializableClosure.php

Can this still be accomplished in 4.x? Again, this is a very large and widely used feature of Laravel so if it's not planned to be supported for 4.x we will likely be forced to fork 3.x and maintain that version ourselves unfortunately. 😬

Answer 10 · 2020-07-07T11:49:22.000Z

Can this still be accomplished in 4.x?

Not at this time, but a similar mechanism can be added in 5 minutes.

However, in 4.x there are no wrappers, meaning that transformUseVariables/resolveUseVariables handlers will apply globally.

Also, since we removed the wrappers you can view a closure as other data type, like an array (from serialization/unserialization perspective), so this should work:

$a = function () use ($laravalModel, $laravelCollection) {};
$b = [$laravelModel, $laravelCollection]; //  array serialization is handled by PHP, so you don't have transform/resolve handlers

unserialize(serialize($a)); // works because we have transform/resolve handlers
unserialize(serialize($b)); // should also work.

If it doesn't work properly then the problem is not related to opis/closure (in my opinion, @msarca what do you think?).

Again, this is a very large and widely used feature of Laravel so if it's not planned to be supported for 4.x we will likely be forced to fork 3.x and maintain that version ourselves unfortunately.

We just added @GrahamCampbell to opis/closure team to help maintain version 3.x for laravel as long as necessary (see #63).

Answer 11 · 2020-07-07T14:54:49.000Z

It would not be a significant problem for us for those handlers to apply globally I don't think.

Answer 12 · 2021-07-05T18:46:33.000Z

Hey, PHP-DI maintainer here 👋 We're using opis/closure too, and I'm worried about the usage of FFI: AFAIK that extension isn't installed by default, is that correct?

@taylorotwell is the FFI requirement an issue with Laravel?

Answer 13 · 2021-07-05T19:52:17.000Z

@mnapoli We are also dependant on ext-tokenizer #92, and nobody ever complained 😅. The FFI extension is a bundled extension, just like ext-tokenizer, ext-pdo, or ext-mbstring, and I don't think it will be an issue.

Answer 14 · 2021-07-06T09:53:58.000Z

The PHP dpcumentation is still warning that the FFI extension is experimental. Using the extension requires the "libffi" library to be installed, and PHP has to be compiled using "--with-ffi".

I have my doubts that distributions will do that by default, and would consider relying on that extension to be risky.

I checked two installations I use: Ubuntu seems to have FFI enabled by default (I did not remember installing it explicitly), but Suse Linux Enterprise does not - as this is used in my production system, I'd have to investigate what is offered as optional extension there.

Answer 15 · 2021-07-09T08:46:36.000Z

I got feedback from my ops team: Suse Linux is not yet providing the FFI extension. If we'd ask them to provide it, it would go only into their latest release, which is SLES15SP3.

Answer 16 · 2022-01-21T15:40:15.000Z

Hi,

I guess version 4.x doesn't work with PHP 8.1, at least for me.

Dockerfile:

FROM php:8.1-fpm
RUN docker-php-source extract \
&& apt-get update \
&& apt-get install libffi-dev && docker-php-ext-configure ffi --with-ffi && docker-php-ext-install ffi \
&& docker-php-source delete

php.ini:

extension=ffi.so
ffi.enable = true

test.php

<?php

declare(strict_types=1);

require __DIR__ . '/../vendor/autoload.php';

\Opis\Closure\Library::init();

$f = fn() => 'Hello';
$data = serialize($f);
$g = unserialize($data);
echo $g(); //> Hello

Output:

tomaskudelka@tomas-air sandbox % php test.php

Fatal error: Uncaught Exception: Serialization of 'Closure' is not allowed in /var/www/html/www/index.php:11
Stack trace:
#0 /var/www/html/www/index.php(11): serialize(Object(Closure))
#1 {main}
  thrown in /var/www/html/www/index.php on line 11

With PHP 8.0 and same configuration everything works fine.

Answer 17 · 2022-01-21T16:28:07.000Z

@driesvints removed your comment for being off topic

Answer 18 · 2022-01-21T16:30:21.000Z

@msarca sure, it's your privilege to maintain this repo how you prefer. Was just trying to help @thorewi

Answer 19 · 2022-01-21T16:44:26.000Z

@driesvints yes, thank you, I know the another library...

Answer 20 · 2022-01-21T16:55:06.000Z

@thorewi will take a look and try to fix it. @driesvints I appreciate your understanding.

Answer 21 · 2024-08-20T18:43:25.000Z

A huge feature of Laravel is queued Closures with proper ORM model serialization / deserialization when the models are part of the use portion of the Closure. We accomplished this in previous versions of Opis by overwriting methods that I had PR'd to Opis...

My original PR to Opis: #21

Our overwritten methods can be seen here: https://github.com/illuminate/queue/blob/master/SerializableClosure.php

Can this still be accomplished in 4.x? Again, this is a very large and widely used feature of Laravel so if it's not planned to be supported for 4.x we will likely be forced to fork 3.x and maintain that version ourselves unfortunately. 😬

I have written a new serialization library that supports serializing closures without wrapping them. Also it supports serializing readonly Closure properties. I haven't released it yet (it will be part of another library instead) but if there is need I can.