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 <theanomaly...@gmail.com>
wrote:
>
>
> On Fri, Apr 3, 2020 at 5:16 PM Andrea Faulds <a...@ajf.me> wrote:
>
>> Hey Sara,
>>
>> Sara Golemon wrote:
>> > On Mon, Mar 30, 2020 at 12:38 PM Chase Peeler <chasepee...@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.
>>
>>
> +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
>>
>>
