Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112925
MIME-Version: 1.0
References: <DM6PR07MB66189CC60F94349200D0D02BF9A40@DM6PR07MB6618.namprd07.prod.outlook.com>
In-Reply-To: <DM6PR07MB66189CC60F94349200D0D02BF9A40@DM6PR07MB6618.namprd07.prod.outlook.com>
Date: Tue, 19 Jan 2021 10:59:17 +0100
Message-ID: <CAF+90c9PJ=9NOtLPW_iTaY2=AF97oc6BrXRSqK0+4QNGsYxJbg@mail.gmail.com>
To: tyson andre <tysonandre775@hotmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000355ae305b93de56e"
Subject: Re: [PHP-DEV] Proposal: short_var_export($value, bool $return=false,
 int $flags=0)
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000355ae305b93de56e
Content-Type: text/plain; charset="UTF-8"

On Mon, Jan 18, 2021 at 10:12 PM tyson andre <tysonandre775@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

--000000000000355ae305b93de56e--