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
>
>
