Removed warning about missing namespace leading backslash in `var_export()` 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
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: https://github.com/php/php-src/pull/8232 Ref: https://github.com/php/php-src/pull/8233 Ref: https://github.com/Ocramius/ProxyManager/issues/754
Hmm, but see https://externals.io/message/67008#67010. ;)
Aye, mistakes were made :|
Indeed confusing scope on my end:
serialize()provides a value inside astring, hence always global namespacevar_export()provides a code snippet, hence contextual to execution scope
Sorry for my previous mistake on that: my idea of var_export() was indeed broken.
See also https://github.com/php/php-src/pull/8233#issuecomment-1073961831
Should probably also add a row in the Changelog, and update Examples, as was done in https://github.com/php/doc-en/compare/68601c39b9543a3d848e01f90f1fbb5512f39929%5E...9ddc8b69468da104704dadf9fb8d22480c7ad687?
Thanks @guilliamxavier: will try emulating that patch here, once https://github.com/php/php-src/pull/8233 is merged
This feels like it needs a changelog entry for 8.2 to explain the change (and also added to the migration guide/UPGRADING file, as that somehow didn't get done, so the change got missed).
Otherwise, I don't really mind dropping it, but I think it may be useful to have it somewhere that details the nuance and pitfall.
I just landed https://github.com/php/doc-en/commit/0f27fadf81b66268edf545f13891401b4d53cc38, so this ticket can be closed. Thanks everybody!