Everything

php

[RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

php.internals

Sherif Ramadan

6 years ago

I'm proposing a new RFC to change var_export()'s array syntax to use the
short hand array syntax instead.

The RFC is available here https://wiki.php.net/rfc/var-export-array-syntax

This is a forwards-compatible change proposed for and targeting PHP 8.0.

I'd like to open up discussion.

Benjamin Morel

6 years ago

+1 for this.

This is the syntax I'm using in brick/varexporter
<https://github.com/brick/varexporter>, and supporting it natively in
var_export() makes sense.

— Benjamin

Sara Golemon

6 years ago

On Sun, Mar 29, 2020 at 3:43 PM Benjamin Morel <benjamin.morel@gmail.com>
wrote:

> This is the syntax I'm using in brick/varexporter
> <https://github.com/brick/varexporter>, and supporting it natively in
> var_export() makes sense.
>
>

Ditto Danack's question, adding: "Then why not use brick/varexporter?"

-Sara

Benjamin Morel

6 years ago

>
> "Then why not use brick/varexporter?"

As much as I'm pleased that people use this library, I consider it a shim,
waiting for PHP to ultimately provide the same functionality.
See the (object) cast for stdClass, that was supported by varexporter but
was later added to var_export().
I don't see a reason not to follow with the short array syntax; the only
expectation of people using var_export(), AFAIK, is to get valid PHP code;
they don't care about the syntax, which will be retro-compatible as far as
PHP 5.4, if that's even a consideration when PHP 8.0 is released.

— Benjamin

Sara Golemon

6 years ago

On Mon, Mar 30, 2020 at 9:06 AM Benjamin Morel <benjamin.morel@gmail.com>
wrote:

> I don't see a reason not to follow with the short array syntax; the only
>> expectation of people using var_export(), AFAIK, is to get valid PHP code;
>> they don't care about the syntax,
>
>

If "they" don't care about syntax, then why do you?

-Sara

Aimeos | Norbert Sendetzky

6 years ago

Am 30.03.20 um 16:39 schrieb Sara Golemon:

>> I don't see a reason not to follow with the short array syntax; the only
>>> expectation of people using var_export(), AFAIK, is to get valid PHP code;
>>> they don't care about the syntax,
>>
> If "they" don't care about syntax, then why do you?

The output is much easier to read and less cluttered if you do debugging
and thus I support Benjamin's proposal.


Norbert

Benjamin Morel

6 years ago

>
> If "they" don't care about syntax, then why do you?

Sorry I was unclear. I was reacting to the argument about broken tests in
php-src.
I meant: they don't have *expectations* about the syntax, but they'll most
likely want to be able to read it.

— Benjamin

Sara Golemon

6 years ago

On Mon, Mar 30, 2020 at 11:39 AM Benjamin Morel <benjamin.morel@gmail.com>
wrote:

> If "they" don't care about syntax, then why do you?
>
>
> Sorry I was unclear. I was reacting to the argument about broken tests in
> php-src.
> I meant: they don't have *expectations* about the syntax, but they'll most
> likely want to be able to read it.
>
> And we circle back to the current syntax being perfectly readable. We

could keep this up all quarantine...

In a more practical example,
https://github.com/php/web-php/blob/master/include/releases.inc is an
example of a var_export() generated file that lives in the wild and is
regularly updated.

I would say it's fairly readable, HOWEVER I WOULD AGREE WITH YOU that it
would be MORE readable using short array syntax and skipping the index
numbers.  In fact, I had exactly this thought nearly 3 years ago when I
started touching this file regularly. (plus the fact that the structure of
this array is kinda gross).

You'll note though, that I'm not championing making this file more
reasonable. Because it doesn't matter.  Because accidental damage to
existing code isn't worth a minor bit of aesthetics by a file which is
primarily read by machines.  If it really mattered to me in any meaningful
way, I'd write the dozen or so lines of script needed to output in a
"pretty" way.  Or I'd go google and find brick/varexporter.

Lastly, there are at least six RMs at any given moment working on PHP's
release.  Can you imagine if we were updating this file using different
versions?  The git churn would be horrific.  Do not want.  If we really
wanted "pretty var_export", then there'd be no real choice BUT to use a
library script to do the serializing.

-Sara

Chase Peeler

6 years ago

On Mon, Mar 30, 2020 at 1:32 PM Sara Golemon <pollita@php.net> wrote:

> On Mon, Mar 30, 2020 at 11:39 AM Benjamin Morel <benjamin.morel@gmail.com>
> wrote:
>
> > If "they" don't care about syntax, then why do you?
> >
> >
> > Sorry I was unclear. I was reacting to the argument about broken tests in
> > php-src.
> > I meant: they don't have *expectations* about the syntax, but they'll
> most
> > likely want to be able to read it.
> >
> > And we circle back to the current syntax being perfectly readable. We
> could keep this up all quarantine...
>
> In a more practical example,
> https://github.com/php/web-php/blob/master/include/releases.inc is an
> example of a var_export() generated file that lives in the wild and is
> regularly updated.
>
> I would say it's fairly readable, HOWEVER I WOULD AGREE WITH YOU that it
> would be MORE readable using short array syntax and skipping the index
> numbers.  In fact, I had exactly this thought nearly 3 years ago when I
> started touching this file regularly. (plus the fact that the structure of
> this array is kinda gross).
>
> You'll note though, that I'm not championing making this file more
> reasonable. Because it doesn't matter.  Because accidental damage to
> existing code isn't worth a minor bit of aesthetics by a file which is
> primarily read by machines.  If it really mattered to me in any meaningful
> way, I'd write the dozen or so lines of script needed to output in a
> "pretty" way.  Or I'd go google and find brick/varexporter.
>
> Lastly, there are at least six RMs at any given moment working on PHP's
> release.  Can you imagine if we were updating this file using different
> versions?  The git churn would be horrific.  Do not want.  If we really
> wanted "pretty var_export", then there'd be no real choice BUT to use a
> library script to do the serializing.
>
> -Sara
>

I'm with Sara on this, which shouldn't be a big surprise.

Just out of curiosity, is there any reason we couldn't add an optional
parameter called "$short_array" or whatever that defaults to false? Then
there shouldn't be any backwards compatibility issues.

--
Chase Peeler
chasepeeler@gmail.com

Derick Rethans

6 years ago

On Mon, 30 Mar 2020, Chase Peeler wrote:

> Just out of curiosity, is there any reason we couldn't add an optional
> parameter called "$short_array" or whatever that defaults to false?
> Then there shouldn't be any backwards compatibility issues.

And then you'd have to maintain two behaviours, and a flag, and their
test files.

cheers,
Derick

Sara Golemon

6 years ago

On Mon, Mar 30, 2020 at 12:38 PM Chase Peeler <chasepeeler@gmail.com> wrote:

> Just out of curiosity, is there any reason we couldn't add an optional
> parameter called "$short_array" or whatever that defaults to false? Then
> there shouldn't be any backwards compatibility issues.
>
> None at all, though I'd make it an `int $options = 0` similar to

json_encode().  I'd have a FAR easier time supporting that than a wholesale
BC break for the sake of breaking BC.

I can think of a few options:
VAR_EXPORT_SHORT_ARRAY => use [] instead of arrray()
VAR_EXPORT_NO_WHITESPACE => Keep it concise, single line
VAR_EXPORT_NO_VECTOR_INDEX => If an array is vector-like, skip indexes
VAR_EXPORT_UTF8_UESCAPE => Detect places where we can use \u{1234} syntax
for UTF8 strings

Though I'm going to stay with my stated position that I would MUCH rather
this stuff live in userspace.  Just because PHP's penchant for
including the kitchen sink is broken already doesn't mean we should break
it more.

-Sara

-Sara

Andrew Faulds

6 years ago

Hey Sara,

Sara Golemon wrote:

> On Mon, Mar 30, 2020 at 12:38 PM Chase Peeler <chasepeeler@gmail.com> wrote:
>
>> Just out of curiosity, is there any reason we couldn't add an optional
>> parameter called "$short_array" or whatever that defaults to false? Then
>> there shouldn't be any backwards compatibility issues.
>>
>> None at all, though I'd make it an `int $options = 0` similar to
> json_encode().  I'd have a FAR easier time supporting that than a wholesale
> BC break for the sake of breaking BC.
>
> I can think of a few options:
>    VAR_EXPORT_SHORT_ARRAY => use [] instead of arrray()
>    VAR_EXPORT_NO_WHITESPACE => Keep it concise, single line
>    VAR_EXPORT_NO_VECTOR_INDEX => If an array is vector-like, skip indexes
>    VAR_EXPORT_UTF8_UESCAPE => Detect places where we can use \u{1234} syntax
> for UTF8 strings
>
> Though I'm going to stay with my stated position that I would MUCH rather
> this stuff live in userspace.  Just because PHP's penchant for
> including the kitchen sink is broken already doesn't mean we should break
> it more.

As you say, including the kitchen sink might be excessive, but I think
adding a $flags option isn't a bad idea — it's low-maintenance, simple
to implement and, in my opinion, would be frequently used. We can have
the best of both worlds: consistent default behaviour, and nicer output
for those who want it. I can see myself using VAR_EXPORT_SHORT_ARRAY and
VAR_EXPORT_NO_VECTOR_INDEX (not with that name…) :)

(Also, if we make the output of var_export() more palatable, will people
use it instead of print_r() for development purposes? I can dream…)

Thanks,
Andrea

Sherif Ramadan

6 years ago

@Sara Golemon <pollita@php.net>

> Ditto Danack's question, adding: "Then why not use brick/varexporter?"
>
> -Sara
>

I punt the question back to you and ask why not use PHP?

Sara Golemon

6 years ago

On Mon, Mar 30, 2020 at 10:56 AM Sherif Ramadan <theanomaly.is@gmail.com>
wrote:

> @Sara Golemon <pollita@php.net>
>
>
>> Ditto Danack's question, adding: "Then why not use brick/varexporter?"
>>
>> -Sara
>>
>
> I punt the question back to you and ask why not use PHP?
>
> Simple. Because an implementation in script code is more agile, more

accessible, and more maintainable in the long term. It's better in every
way except default availability.  Considering the *1 line* required to make
it available in a project, this is not a compelling reason.  Conversely,
avoiding unnecessary breakage of existing code over a matter of aesthetics
IS a compelling reason.

Now, will you answer my question?

-Sara

Sherif Ramadan

6 years ago

On Mon, Mar 30, 2020 at 1:19 PM Sara Golemon <pollita@php.net> wrote:

> On Mon, Mar 30, 2020 at 10:56 AM Sherif Ramadan <theanomaly.is@gmail.com>
> wrote:
>
>> @Sara Golemon <pollita@php.net>
>>
>>
>>> Ditto Danack's question, adding: "Then why not use brick/varexporter?"
>>>
>>> -Sara
>>>
>>
>> I punt the question back to you and ask why not use PHP?
>>
>> Simple. Because an implementation in script code is more agile, more
> accessible, and more maintainable in the long term. It's better in every
> way except default availability.  Considering the *1 line* required to make
> it available in a project, this is not a compelling reason.  Conversely,
> avoiding unnecessary breakage of existing code over a matter of aesthetics
> IS a compelling reason.
>
> Now, will you answer my question?
>

Simple. Because an implement in php-src is more available, does not appear
to have a lot of maintenance overhead, is easy to implement and it's better
in every way. Considering the 6 lines of code required to make this change
available to everyone. Given that code is meant for human consumption and
given that aesthetics play a big role in code readability I would say that
conversely doing it IS a compelling reason.

Apart from the 25 phpt tests that (in my opinion) are testing the wrong
thing in the first place, what major projects do you know of that would
break as a result of this change? And I'm not talking about more tests that
test the output of var_export() because that's a breakage I can live with.
If you were using the function as intended you would only be testing that
it gives you back valid PHP code and not trying to test its literal output.

Sara Golemon

6 years ago

On Mon, Mar 30, 2020 at 12:32 PM Sherif Ramadan <theanomaly.is@gmail.com>
wrote:

> Now, will you answer my question?
>>
>
> Simple.
>

Wrong. It's complex as this thread proves. Opinions are not in alignment
making it non-simple.

> Because an implement in php-src is more available,
>

Wrong. It's got availability FOR THOSE ON THE LATEST VERSION. It is LESS
available for those on older versions.

> does not appear to have a lot of maintenance overhead,
>

Neither does brick/varexporter, this point is irrelevant.

> is easy to implement
>

The format you want is already implemented.  Done is easier than TODO.

> and it's better in every way.
>

Wrong. Please consider reading my earlier reply.

> Given that code is meant for human consumption
>

Wrong. It is meant for machine consumption.

> I would say that conversely doing it IS a compelling reason.
>
> Wrong due to every part of your statement being wrong.

All the best.
-Sara

Derick Rethans

6 years ago

On Mon, 30 Mar 2020, Sherif Ramadan wrote:

> Given that code is meant for human consumption

I have already told you that the output of this function was never meant
for human consumption.

It was originally added to aid in caching of larger complicated data
structure through the likes of apc's opcode cache.

cheers,
Derick

--
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

Morgan Breden

6 years ago

> I have already told you that the output of this function was never meant
> for human consumption.

> It was originally added to aid in caching of larger complicated data
> structure through the likes of apc's opcode cache.

It is sometimes used for human consumption now, though. For example,
my team often uses it to generate database seeders from staging
environments.

With respect, I don't think "I didn't intend this to be used in the way it
is
now used" is a compelling argument against improving something, rather
it's an argument *for* improvement in my eyes. Other arguments here not
withstanding.

On Mon, Mar 30, 2020 at 5:45 PM Derick Rethans <derick@php.net> wrote:

Andrew Faulds

6 years ago

Hi Sherif,

Sherif Ramadan wrote:

> I'm proposing a new RFC to change var_export()'s array syntax to use the
> short hand array syntax instead.
>
> The RFC is available here https://wiki.php.net/rfc/var-export-array-syntax
>
> This is a forwards-compatible change proposed for and targeting PHP 8.0.
>
> I'd like to open up discussion.
>

What about stdClass? That is currently exported using an object cast
applied to an array literal, and that array literal uses long array
syntax for consistency. I think this should be mentioned in the RFC,
whatever choice you make.

Regards,
Andrea

Andrew Faulds

6 years ago

Hi again,

Andrea Faulds wrote:

> Hi Sherif,
>
> Sherif Ramadan wrote:
>> I'm proposing a new RFC to change var_export()'s array syntax to use the
>> short hand array syntax instead.
>>
>> The RFC is available here
>> https://wiki.php.net/rfc/var-export-array-syntax
>>
>> This is a forwards-compatible change proposed for and targeting PHP 8.0.
>>
>> I'd like to open up discussion.
>>
>
> What about stdClass? That is currently exported using an object cast
> applied to an array literal, and that array literal uses long array
> syntax for consistency. I think this should be mentioned in the RFC,
> whatever choice you make.

Oops, I forgot about classes with ::__set_state! (I only thought about
stdClass because it was me that added support for it, unlike for
__set_state.) That also uses the old array syntax.

Thanks and sorry for spam,
Andrea

Dan Ackroyd

6 years ago

On Sun, 29 Mar 2020 at 18:51, Sherif Ramadan <theanomaly.is@gmail.com> wrote:

>
> I'm proposing a new RFC to change var_export()'s array syntax to use the
> short hand array syntax instead.
>

"The old array() construct is a kludge and is unappealing."

That's an aesthetic choice, which not everyone will agree with.

"There shouldn't be any backwards incompatible changes"

It apparently breaks 25 tests that compare the output of var_export
with an expected version. Userland users who have similar tests will
experience similar breaks.

Is there any reason to do this change other than aesthetic choice?

cheers
Dan
Ack

Sherif Ramadan

6 years ago

@Dan Ackroyd <danack@basereality.com>

> That's an aesthetic choice, which not everyone will agree with.
>

Yes, I freely state that in the RFC. Everyone is free to vote how they like.

>
> "There shouldn't be any backwards incompatible changes"
>
> It apparently breaks 25 tests that compare the output of var_export
> with an expected version. Userland users who have similar tests will
> experience similar breaks.
>
>

A test that compares var_export output is a pretty broken test, in my
opinion. This is similar to a test that would use the value of a constant
to test that the constant works. You're testing PHP code you shouldn't care
if it uses the long form array construct or short form. Just test that it
gives you an array.

With that said, I will update the RFC to make note of these tests and I
will fix them should the RFC be voted in.

> Is there any reason to do this change other than aesthetic choice?
>
>

Just because it is aesthetic is not actually an argument against. Why
wouldn't you want to improve the aesthetics of PHP? Is it only an aesthetic
choice, however? Not entirely. I also state that it is easier to read and
type (saves space) and is more inline with JSON notation which is a lot
more ubiquitous these days. These are all pros. I see no cons in that
change.

Derick Rethans

6 years ago

On 30 March 2020 16:54:55 BST, Sherif Ramadan <theanomaly.is@gmail.com> wrote:

>@Dan Ackroyd <danack@basereality.com>
>
>> Is there any reason to do this change other than aesthetic choice?
>>
>>
>Just because it is aesthetic is not actually an argument against. Why
>wouldn't you want to improve the aesthetics of PHP? Is it only an
>aesthetic
>choice, however?

I added this function to be able to create a PHP variable structure expressed as PHP code, so that the PHP parser can construct it back into variable structure.

Aesthetics are irrelevant for a computer.

This change does not improve anything and only breaks compatibility. Bad idea.

cheers,
Derick

Sherif Ramadan

6 years ago

>
>
> Aesthetics are irrelevant for a computer.
>
> This change does not improve anything and only breaks compatibility. Bad
> idea.
>
>

I beg to differ. While code may be meant for execution by a machine it is
actually intended for human consumption. Aesthetics matter to a human
reading the code.