Re: [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays

On Fri, Apr 3, 2020 at 5:16 PM Andrea Faulds <ajf@ajf.me> wrote: > 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. > > +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 > >