Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays
> > > I have no strong opinion > either way, but anyway it cannot work as is, because var_export > already has a second optional parameter (bool $return = false). > Yes, I meant the third argument. I updated the RFC to reflect that. Sorry. > Moreover the RFC currently says that var_export([1, 2, 3]) produces > ``` > array(1, 2, 3) > ``` > but it actually produces > ``` > array ( > 0 => 1, > 1 => 2, > 2 => 3, > ) > ``` > > Also true, I fixed this in the RFC as well and sorry for the confusion. > Regards, > > -- > Guilliam Xavier >
Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays
On Wed, Apr 8, 2020 at 9:37 AM Derick Rethans wrote: > > It's different. Changing from long to short array syntax makes it > unparsable by older versions of PHP. > All versions of PHP which don't support short array syntax have long been EOL for nearly 5 years now. We can't possibly be expected to account for unsupported versions of PHP here.
Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays
On Wed, Apr 8, 2020 at 3:12 PM Sherif Ramadan wrote: > > So to recap on what's been discussed so far, because I plan to bring this > to a vote next week... > > I am updating the RFC to reflect that the change will no longer break > backwards compatibility. I will be adding an flags argument with the > following 3 optional bitwise flags for var_export: > > - VAR_EXPORT_SHORT_ARRAY [Triggers short-array syntax] > - VAR_EXPORT_NO_INDEX [Discards numbered indexes in arrays (only if they > are sequential from 0)] > - VAR_EXPORT_NO_WHITESPACE [For one-liners] > > This complicates the implementation slightly, but I think it brings a > greater net-benefit. Hello, First, thank you for proposing this RFC. I have no strong opinion either way, but anyway it cannot work as is, because var_export already has a second optional parameter (bool $return = false). You could add the flags as a third optional parameter (int $options = 0), or maybe make it replace (extend) the existing one and add an extra constant, say VAR_EXPORT_RETURN = 1, so that it can be combined (although I'm not sure that changing the type from bool to int (or maybe bool|int) would be BC-compliant...) Moreover the RFC currently says that var_export([1, 2, 3]) produces ``` array(1, 2, 3) ``` but it actually produces ``` array ( 0 => 1, 1 => 2, 2 => 3, ) ``` Regards, -- Guilliam Xavier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays
> On Apr 8, 2020, at 08:37, Derick Rethans wrote: > > I still believe that none of these options are needed. var_export() has > been added to generate PHP parser readable code. I think it was said earlier, but I'll say it again: having it generate parser-readable code is great, but having it optionally generate pleasantly-readable code (e.g. to be used as $actual in tests) would also be great. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays
On Wed, 8 Apr 2020, Sherif Ramadan wrote: > On Wed, Apr 8, 2020 at 9:22 AM Benjamin Morel > wrote: > > > > VAR_EXPORT_NO_INDEX > > > > Note that I wouldn't consider a BC break to change var_export()'s > > behaviour to always discard indexes when they're numeric, I'm not > > sure this should even be an option! > > > > > Well, it might if people are testing the output of var_export(), like in > the phpt tests. I wouldn't have considered the short array syntax a BC > break either if it weren't for that little pot hole. It's different. Changing from long to short array syntax makes it unparsable by older versions of PHP. I still believe that none of these options are needed. var_export() has been added to generate PHP parser readable code. And these options are extra complexity adds no new functionality. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays
On Wed, Apr 8, 2020 at 9:22 AM Benjamin Morel wrote: > > VAR_EXPORT_NO_INDEX > > Note that I wouldn't consider a BC break to change var_export()'s > behaviour to always discard indexes when they're numeric, I'm not sure this > should even be an option! > > Well, it might if people are testing the output of var_export(), like in the phpt tests. I wouldn't have considered the short array syntax a BC break either if it weren't for that little pot hole. > - Ben >
Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays
> VAR_EXPORT_NO_INDEX Note that I wouldn't consider a BC break to change var_export()'s behaviour to always discard indexes when they're numeric, I'm not sure this should even be an option! - Ben
Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays
So to recap on what's been discussed so far, because I plan to bring this
to a vote next week...
I am updating the RFC to reflect that the change will no longer break
backwards compatibility. I will be adding an flags argument with the
following 3 optional bitwise flags for var_export:
- VAR_EXPORT_SHORT_ARRAY [Triggers short-array syntax]
- VAR_EXPORT_NO_INDEX [Discards numbered indexes in arrays (only if they
are sequential from 0)]
- VAR_EXPORT_NO_WHITESPACE [For one-liners]
This complicates the implementation slightly, but I think it brings a
greater net-benefit.
On Fri, Apr 3, 2020 at 5:19 PM Sherif Ramadan
wrote:
>
>
> On Fri, Apr 3, 2020 at 5:16 PM Andrea Faulds wrote:
>
>> Hey Sara,
>>
>> Sara Golemon wrote:
>> > On Mon, Mar 30, 2020 at 12:38 PM 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.
>> >>
>> >> 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.
>>
>>
> +1 for me
>
>
>> 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…) :)
>>
>
> *Fingers crossed*
>
>
>> (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
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays
On Fri, Apr 3, 2020 at 5:16 PM Andrea Faulds wrote:
> Hey Sara,
>
> Sara Golemon wrote:
> > On Mon, Mar 30, 2020 at 12:38 PM 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.
> >>
> >> 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.
>
>
+1 for me
> 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…) :)
>
*Fingers crossed*
> (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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays
Hey Sara,
Sara Golemon wrote:
On Mon, Mar 30, 2020 at 12:38 PM 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.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
