Removed warning about missing namespace leading backslash in var_export() docs

[Ocramius]

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: php/php-src#8232
Ref: php/php-src#8233
Ref: Ocramius/ProxyManager#754

[cmb69]

Hmm, but see https://externals.io/message/67008#67010. ;)

[Ocramius]

Aye, mistakes were made :|

Indeed confusing scope on my end:

• serialize() provides a value inside a string, hence always global namespace
• var_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 php/php-src#8233 (comment)

[guilliamxavier]

Should probably also add a row in the Changelog, and update Examples, as was done in 68601c39b9543a3d848e01f90f1fbb5512f39929^...9ddc8b6?

[Ocramius]

Thanks @guilliamxavier: will try emulating that patch here, once php/php-src#8233 is merged

[TimWolla]

This makes sense to me, especially with the change in php/php-src#8233. Users should not make any assumptions about the output, except that the return value is a valid PHP expression.

[Girgias]

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.

[cmb69]

I just landed 0f27fad, so this ticket can be closed. Thanks everybody!