-
Notifications
You must be signed in to change notification settings - Fork 7.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
var_export()
combined with enum
produces code unsuitable for inclusion in namespaces
#8232
Comments
Seems like this applies to both |
This fix corrects a behavior of `var_export()` that was mostly "hidden" until PHP 8.1 introduced: * properties with object initializers * constants containing object references * default values of class properties containing `enum`s Since `var_export(..., true)` is mostly used in conjunction with code generation, and we cannot make assumptions about the generated code being placed in the root namespace, we must always provide the FQCN of a class in exported code. For example: ```php <?php namespace MyNamespace { class Foo {} } namespace { echo "<?php\n\nnamespace Example;\n\n" . var_export(new \MyNamespace\Foo(), true) . ';'; } ``` produces: ```php <?php namespace Example; MyNamespace\Foo::__set_state(array( )); ``` This code snippet is invalid, because `Example\MyNamespace\Foo::__set_state()` (which does not exist) is called. With this patch applied, the code looks like following (valid): ```php <?php namespace Example; \MyNamespace\Foo::__set_state(array( )); ``` Ref: php#8232 Ref: Ocramius/ProxyManager#754
This fix corrects a behavior of `var_export()` that was mostly "hidden" until PHP 8.1 introduced: * properties with object initializers * constants containing object references * default values of class properties containing `enum`s Since `var_export(..., true)` is mostly used in conjunction with code generation, and we cannot make assumptions about the generated code being placed in the root namespace, we must always provide the FQCN of a class in exported code. For example: ```php <?php namespace MyNamespace { class Foo {} } namespace { echo "<?php\n\nnamespace Example;\n\n" . var_export(new \MyNamespace\Foo(), true) . ';'; } ``` produces: ```php <?php namespace Example; MyNamespace\Foo::__set_state(array( )); ``` This code snippet is invalid, because `Example\MyNamespace\Foo::__set_state()` (which does not exist) is called. With this patch applied, the code looks like following (valid): ```php <?php namespace Example; \MyNamespace\Foo::__set_state(array( )); ``` Ref: php#8232 Ref: Ocramius/ProxyManager#754
This fix corrects a behavior of `var_export()` that was mostly "hidden" until PHP 8.1 introduced: * properties with object initializers * constants containing object references * default values of class properties containing `enum`s Since `var_export(..., true)` is mostly used in conjunction with code generation, and we cannot make assumptions about the generated code being placed in the root namespace, we must always provide the FQCN of a class in exported code. For example: ```php <?php namespace MyNamespace { class Foo {} } namespace { echo "<?php\n\nnamespace Example;\n\n" . var_export(new \MyNamespace\Foo(), true) . ';'; } ``` produces: ```php <?php namespace Example; MyNamespace\Foo::__set_state(array( )); ``` This code snippet is invalid, because `Example\MyNamespace\Foo::__set_state()` (which does not exist) is called. With this patch applied, the code looks like following (valid): ```php <?php namespace Example; \MyNamespace\Foo::__set_state(array( )); ``` Ref: php#8232 Ref: Ocramius/ProxyManager#754
This fix corrects a behavior of `var_export()` that was mostly "hidden" until PHP 8.1 introduced: * properties with object initializers * constants containing object references * default values of class properties containing `enum`s Since `var_export(..., true)` is mostly used in conjunction with code generation, and we cannot make assumptions about the generated code being placed in the root namespace, we must always provide the FQCN of a class in exported code. For example: ```php <?php namespace MyNamespace { class Foo {} } namespace { echo "<?php\n\nnamespace Example;\n\n" . var_export(new \MyNamespace\Foo(), true) . ';'; } ``` produces: ```php <?php namespace Example; MyNamespace\Foo::__set_state(array( )); ``` This code snippet is invalid, because `Example\MyNamespace\Foo::__set_state()` (which does not exist) is called. With this patch applied, the code looks like following (valid): ```php <?php namespace Example; \MyNamespace\Foo::__set_state(array( )); ``` Ref: php#8232 Ref: Ocramius/ProxyManager#754
This fix corrects a behavior of `var_export()` that was mostly "hidden" until PHP 8.1 introduced: * properties with object initializers * constants containing object references * default values of class properties containing `enum`s Since `var_export(..., true)` is mostly used in conjunction with code generation, and we cannot make assumptions about the generated code being placed in the root namespace, we must always provide the FQCN of a class in exported code. For example: ```php <?php namespace MyNamespace { class Foo {} } namespace { echo "<?php\n\nnamespace Example;\n\n" . var_export(new \MyNamespace\Foo(), true) . ';'; } ``` produces: ```php <?php namespace Example; MyNamespace\Foo::__set_state(array( )); ``` This code snippet is invalid, because `Example\MyNamespace\Foo::__set_state()` (which does not exist) is called. With this patch applied, the code looks like following (valid): ```php <?php namespace Example; \MyNamespace\Foo::__set_state(array( )); ``` Ref: php#8232 Ref: Ocramius/ProxyManager#754
…ort()` docs `var_export()` needs to prefix classes it references with `\`, because its code could be transplanted in any source location/namespace, so the assumption of it being used only in the context of the root namespace is not sufficient. For example, in a code snippet like following ( https://3v4l.org/4mONc ): ```php <?php class SomeObject {} var_export([new SomeObject]); ``` This should produce: ``` array ( 0 => \SomeObject::__set_state(array( )), ) ``` Userland should not concern itself with the contents of the `var_export()`-produced code snippets, and use them as-is instead. Ref: php/php-src#8232 Ref: php/php-src#8233 Ref: Ocramius/ProxyManager#754
This fix corrects a behavior of `var_export()` that was mostly "hidden" until PHP 8.1 introduced: * properties with object initializers * constants containing object references * default values of class properties containing `enum`s Since `var_export(..., true)` is mostly used in conjunction with code generation, and we cannot make assumptions about the generated code being placed in the root namespace, we must always provide the FQCN of a class in exported code. For example: ```php <?php namespace MyNamespace { class Foo {} } namespace { echo "<?php\n\nnamespace Example;\n\n" . var_export(new \MyNamespace\Foo(), true) . ';'; } ``` produces: ```php <?php namespace Example; MyNamespace\Foo::__set_state(array( )); ``` This code snippet is invalid, because `Example\MyNamespace\Foo::__set_state()` (which does not exist) is called. With this patch applied, the code looks like following (valid): ```php <?php namespace Example; \MyNamespace\Foo::__set_state(array( )); ``` Ref: php#8232 Ref: Ocramius/ProxyManager#754
This fix corrects a behavior of `var_export()` that was mostly "hidden" until PHP 8.1 introduced: * properties with object initializers * constants containing object references * default values of class properties containing `enum`s Since `var_export(..., true)` is mostly used in conjunction with code generation, and we cannot make assumptions about the generated code being placed in the root namespace, we must always provide the FQCN of a class in exported code. For example: ```php <?php namespace MyNamespace { class Foo {} } namespace { echo "<?php\n\nnamespace Example;\n\n" . var_export(new \MyNamespace\Foo(), true) . ';'; } ``` produces: ```php <?php namespace Example; MyNamespace\Foo::__set_state(array( )); ``` This code snippet is invalid, because `Example\MyNamespace\Foo::__set_state()` (which does not exist) is called. With this patch applied, the code looks like following (valid): ```php <?php namespace Example; \MyNamespace\Foo::__set_state(array( )); ``` Ref: php#8232 Ref: Ocramius/ProxyManager#754
This fix corrects a behavior of `var_export()` that was mostly "hidden" until PHP 8.1 introduced: * properties with object initializers * constants containing object references * default values of class properties containing `enum`s Since `var_export(..., true)` is mostly used in conjunction with code generation, and we cannot make assumptions about the generated code being placed in the root namespace, we must always provide the FQCN of a class in exported code. For example: ```php <?php namespace MyNamespace { class Foo {} } namespace { echo "<?php\n\nnamespace Example;\n\n" . var_export(new \MyNamespace\Foo(), true) . ';'; } ``` produces: ```php <?php namespace Example; MyNamespace\Foo::__set_state(array( )); ``` This code snippet is invalid, because `Example\MyNamespace\Foo::__set_state()` (which does not exist) is called. With this patch applied, the code looks like following (valid): ```php <?php namespace Example; \MyNamespace\Foo::__set_state(array( )); ``` Ref: php#8232 Ref: Ocramius/ProxyManager#754
This fix corrects a behavior of `var_export()` that was mostly "hidden" until PHP 8.1 introduced: * properties with object initializers * constants containing object references * default values of class properties containing `enum`s Since `var_export(..., true)` is mostly used in conjunction with code generation, and we cannot make assumptions about the generated code being placed in the root namespace, we must always provide the FQCN of a class in exported code. For example: ```php <?php namespace MyNamespace { class Foo {} } namespace { echo "<?php\n\nnamespace Example;\n\n" . var_export(new \MyNamespace\Foo(), true) . ';'; } ``` produces: ```php <?php namespace Example; MyNamespace\Foo::__set_state(array( )); ``` This code snippet is invalid, because `Example\MyNamespace\Foo::__set_state()` (which does not exist) is called. With this patch applied, the code looks like following (valid): ```php <?php namespace Example; \MyNamespace\Foo::__set_state(array( )); ``` Ref: php#8232 Ref: Ocramius/ProxyManager#754
This fix corrects a behavior of `var_export()` that was mostly "hidden" until PHP 8.1 introduced: * properties with object initializers * constants containing object references * default values of class properties containing `enum`s Since `var_export(..., true)` is mostly used in conjunction with code generation, and we cannot make assumptions about the generated code being placed in the root namespace, we must always provide the FQCN of a class in exported code. For example: ```php <?php namespace MyNamespace { class Foo {} } namespace { echo "<?php\n\nnamespace Example;\n\n" . var_export(new \MyNamespace\Foo(), true) . ';'; } ``` produces: ```php <?php namespace Example; MyNamespace\Foo::__set_state(array( )); ``` This code snippet is invalid, because `Example\MyNamespace\Foo::__set_state()` (which does not exist) is called. With this patch applied, the code looks like following (valid): ```php <?php namespace Example; \MyNamespace\Foo::__set_state(array( )); ``` Ref: php#8232 Ref: Ocramius/ProxyManager#754
This fix corrects a behavior of `var_export()` that was mostly "hidden" until PHP 8.1 introduced: * properties with object initializers * constants containing object references * default values of class properties containing `enum`s Since `var_export(..., true)` is mostly used in conjunction with code generation, and we cannot make assumptions about the generated code being placed in the root namespace, we must always provide the FQCN of a class in exported code. For example: ```php <?php namespace MyNamespace { class Foo {} } namespace { echo "<?php\n\nnamespace Example;\n\n" . var_export(new \MyNamespace\Foo(), true) . ';'; } ``` produces: ```php <?php namespace Example; MyNamespace\Foo::__set_state(array( )); ``` This code snippet is invalid, because `Example\MyNamespace\Foo::__set_state()` (which does not exist) is called. With this patch applied, the code looks like following (valid): ```php <?php namespace Example; \MyNamespace\Foo::__set_state(array( )); ``` Ref: php#8232 Ref: Ocramius/ProxyManager#754
This fix corrects a behavior of `var_export()` that was mostly "hidden" until PHP 8.1 introduced: * properties with object initializers * constants containing object references * default values of class properties containing `enum`s Since `var_export(..., true)` is mostly used in conjunction with code generation, and we cannot make assumptions about the generated code being placed in the root namespace, we must always provide the FQCN of a class in exported code. For example: ```php <?php namespace MyNamespace { class Foo {} } namespace { echo "<?php\n\nnamespace Example;\n\n" . var_export(new \MyNamespace\Foo(), true) . ';'; } ``` produces: ```php <?php namespace Example; MyNamespace\Foo::__set_state(array( )); ``` This code snippet is invalid, because `Example\MyNamespace\Foo::__set_state()` (which does not exist) is called. With this patch applied, the code looks like following (valid): ```php <?php namespace Example; \MyNamespace\Foo::__set_state(array( )); ``` Ref: php#8232 Ref: Ocramius/ProxyManager#754
Thanks @iluuu1994! |
Do I get it right that this issue was resolved? |
@AnrDaemon the merge commit is part of |
Thanks. For pre-8.2 solution could be <?=is_object($value) && version_compare(PHP_VERSION, '8.2.0', '<') ? "\\" : ''?><?=var_export($value, true)?>, |
Edit: Only |
What case you are thinking about is not valid? |
@AnrDaemon Sorry, I didn't realize objects were also affected, so the problem is only with |
Yup, that seems the only special case. (As is the stdClass itself.) But in controlled environment (i.e. where you are sure you won't encounter stdClass ever), this workaround is applicable. |
Description
Following code: https://3v4l.org/MKPpJ
Resulted in this output:
But I expected this output instead:
To be more specific:
This allows for generated PHP expressions (primary use-case of
var_export()
) to contain enums.Ref: Ocramius/ProxyManager#754 (comment)
PHP Version
8.1.4
Operating System
No response
The text was updated successfully, but these errors were encountered: