On Mon, Jan 18, 2021 at 10:12 PM tyson andre <tysonandre...@hotmail.com> wrote:
> Hi internals, > > I've created a PR https://github.com/php/php-src/pull/6619 to add an > alternative to var_export(). > The proposed short_var_export() also outputs/returns a parseable > representation of a variable, > but adds requested features for var_export. > > 1. Use `null` instead of `NULL` - the former is recommended by more coding > guidelines (https://www.php-fig.org/psr/psr-2/). > 2. Change the way indentation is done for arrays/objects. > See ext/standard/tests/general_functions/short_var_export1.phpt > (e.g. always indent with 2 spaces, never 3 in objects, and put the > array start on the > same line as the key) > 3. Render lists as `"[\n 'item1',\n]"` rather than `"array(\n 0 => > 'item1',\n)"` > 4. Prepend `\` to class names so that generated code snippets can be used > in > namespaces (e.g. with eval()) without any issues. > 5. Support opt-in `SHORT_VAR_EXPORT_SINGLE_LINE` in `int $flags`. > This will use a single-line representation for arrays/objects, though > strings with embedded newlines will still cause newlines in the output. > (`"['item']"`) > > Changing var_export() itself has been proposed 9 months ago ( > https://externals.io/message/109415) > but the RFC discussion seems to be on hold. > https://externals.io/message/106674#106684 suggested adding a new > function as an alternative. > One of the major objections is that changing var_export() (instead of > adding a new function) would have these drawbacks: > > 1. It would be impractical to backport/polyfill calls with 3 args to older > php versions, if `int $flags` was added. > ArgumentCountErrors are thrown in php 8.0 for too many parameters, and > earlier php versions warn > 2. If defaults were changed, then thousands of unit tests in php-src and > other projects may fail due to > tests expecting the exact representation of a variable, requiring a lot > of work to update tests > > I feel like the user-friendliness of the enhancements makes adding another > function > to PHP worth it. (e.g. copying short_var_export() into a code snippet such > as the expectation for a unit test or a configuration) > I don't believe I've seen an RFC for a separate function before. > > Also, a native C implementation would be much more efficient than a > polyfill implemented in PHP, > e.g. https://github.com/brick/varexporter/issues/14 > > I plan to start an RFC document shortly. Thoughts? > (e.g. for the name, short_var_export() seemed more appropriate than > var_export_short(), pretty_var_export() or canonical_var_export()) > > Thanks, > - Tyson > Hi Tyson, The formatting of var_export is certainly a recurring complaint, and previous discussions were not particularly open to changing current var_export behavior, so adding a new function seems to be the way to address the issue (the alternative would be to add a flag to var_export). I like the idea of the "one line" flag. Actually, this is the main part I'm interested in :) With the one line flag, this produces the ideal formatting for PHPT tests that want to print something like "$v1 + $v2 = $v3". None of our current dumping functions are suitable for this purpose (json_encode comes closest, but has edge cases like lack of NAN support.) Some note: * You should drop the $return parameter and make it always return. As this is primarily an export and not a dumping function, printing to stdout doesn't make sense to me. * For strings, have you considered printing them as double-quoted and escaping more characters? This would avoid newlines in oneline mode. And would allow you to escape more control characters. I also find the current '' . "\0" . '' format for encoding null bytes quite awkward. * I don't like the short_var_export() name. Is "short" really the primary characteristic of this function? Both var_export_pretty and var_export_canonical seem better to me, though I can't say they're great either. I will refrain from proposing real_var_export() ... oops :P Regards, Nikita
