Re: [RFC] var_representation() : readable alternative to var_export()

On Jan 24, 2021, at 05:42, Rowan Tommins <rowan.collins@gmail.com> wrote: > As far as I know I have never had any reason to generate code and then eval() it, and > can't think of a situation where I ever would. If I wanted a machine-readable output from a > variable, I would use serialize() or json_encode(). > > That's not to say that there aren't cases where those requirements do happen, but I > think it is a very niche use case to dedicate two different built-in functions to. There's an interesting edge case where this does become useful. If an evaluable representation of a data structure is written to a file (wrapped with <?php return $x;) and subsequently loaded using require(), the file can be stored in opcache. This is dramatically faster than unserialize() or json_decode(), especially for large structures. What'd be particularly useful for this use case would be a function which behaved similarly to var_export(), but which didn't pretty-print its output, so as to yield a smaller file.