Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109524 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 20999 invoked from network); 3 Apr 2020 22:49:16 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 3 Apr 2020 22:49:16 -0000 To: internals@lists.php.net References: Date: Fri, 3 Apr 2020 23:16:17 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Posted-By: 46.59.72.204 Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays From: ajf@ajf.me (Andrea Faulds) Message-ID: 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