# [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays - Thread: https://externals.io/message/109415 - Original archive: https://news-web.php.net/php.internals/109415 - Started by Sherif Ramadan on 2020-03-29T17:51:05+00:00 - Messages: 34 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/109415.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #109415 — Sherif Ramadan — 2020-03-29T17:51:05+00:00 URL: https://externals.io/message/109415#109415 I'm proposing a new RFC to change `var_export()`'s array syntax to use the short hand array syntax instead. The RFC is available here https://wiki.php.net/rfc/var-export-array-syntax This is a forwards-compatible change proposed for and targeting PHP 8.0. I'd like to open up discussion. --- ## #109420 — Benjamin Morel — 2020-03-29T20:42:57+00:00 URL: https://externals.io/message/109415#109420 · In reply to: #109415 +1 for this. This is the syntax I'm using in brick/varexporter , and supporting it natively in `var_export()` makes sense. — Benjamin --- ## #109439 — Andrea Faulds — 2020-03-29T22:39:38+00:00 URL: https://externals.io/message/109415#109439 · In reply to: #109415 Hi Sherif, Sherif Ramadan wrote: > I'm proposing a new RFC to change `var_export()`'s array syntax to use the > short hand array syntax instead. > > The RFC is available here https://wiki.php.net/rfc/var-export-array-syntax > > This is a forwards-compatible change proposed for and targeting PHP 8.0. > > I'd like to open up discussion. > What about stdClass? That is currently exported using an object cast applied to an array literal, and that array literal uses long array syntax for consistency. I think this should be mentioned in the RFC, whatever choice you make. Regards, Andrea --- ## #109440 — Andrea Faulds — 2020-03-29T22:42:30+00:00 URL: https://externals.io/message/109415#109440 · In reply to: #109439 Hi again, Andrea Faulds wrote: > Hi Sherif, > > Sherif Ramadan wrote: > > […] > > What about stdClass? That is currently exported using an object cast > applied to an array literal, and that array literal uses long array > syntax for consistency. I think this should be mentioned in the RFC, > whatever choice you make. Oops, I forgot about classes with ::__set_state! (I only thought about stdClass because it was me that added support for it, unlike for __set_state.) That also uses the old array syntax. Thanks and sorry for spam, Andrea --- ## #109443 — Sherif Ramadan — 2020-03-30T02:40:54+00:00 URL: https://externals.io/message/109415#109443 Hey Andrea, Thanks for that. Good catch on the stdClass and __set_state parts. I neglected those in RFC, but I will add them. But they are still all forwards compatible changes so no major impact. > Hi again, > > Andrea Faulds wrote: > > […] > > Oops, I forgot about classes with ::__set_state! (I only thought about > stdClass because it was me that added support for it, unlike for > __set_state.) That also uses the old array syntax. > > Thanks and sorry for spam, > Andrea --- ## #109450 — Dan Ackroyd — 2020-03-30T11:44:46+00:00 URL: https://externals.io/message/109415#109450 · In reply to: #109415 > > I'm proposing a new RFC to change `var_export()`'s array syntax to use the > short hand array syntax instead. > "The old array() construct is a kludge and is unappealing." That's an aesthetic choice, which not everyone will agree with. "There shouldn't be any backwards incompatible changes" It apparently breaks 25 tests that compare the output of var_export with an expected version. Userland users who have similar tests will experience similar breaks. Is there any reason to do this change other than aesthetic choice? cheers Dan Ack --- ## #109452 — Sara Golemon — 2020-03-30T13:48:04+00:00 URL: https://externals.io/message/109415#109452 · In reply to: #109420 On Sun, Mar 29, 2020 at 3:43 PM Benjamin Morel wrote: > This is the syntax I'm using in brick/varexporter > , and supporting it natively in > `var_export()` makes sense. > > Ditto Danack's question, adding: "Then why not use brick/varexporter?" -Sara --- ## #109453 — Benjamin Morel — 2020-03-30T14:06:12+00:00 URL: https://externals.io/message/109415#109453 · In reply to: #109452 > > "Then why not use brick/varexporter?" As much as I'm pleased that people use this library, I consider it a shim, waiting for PHP to ultimately provide the same functionality. See the (object) cast for stdClass, that was supported by varexporter but was later added to `var_export()`. I don't see a reason not to follow with the short array syntax; the only expectation of people using `var_export()`, AFAIK, is to get valid PHP code; they don't care about the syntax, which will be retro-compatible as far as PHP 5.4, if that's even a consideration when PHP 8.0 is released. — Benjamin --- ## #109454 — Sara Golemon — 2020-03-30T14:39:09+00:00 URL: https://externals.io/message/109415#109454 · In reply to: #109453 On Mon, Mar 30, 2020 at 9:06 AM Benjamin Morel wrote: > I don't see a reason not to follow with the short array syntax; the only > > […] > > If "they" don't care about syntax, then why do you? -Sara --- ## #109455 — Aimeos | Norbert Sendetzky — 2020-03-30T14:53:09+00:00 URL: https://externals.io/message/109415#109455 · In reply to: #109454 Am 30.03.20 um 16:39 schrieb Sara Golemon: > > […] > If "they" don't care about syntax, then why do you? The output is much easier to read and less cluttered if you do debugging and thus I support Benjamin's proposal. Norbert --- ## #109456 — Sherif Ramadan — 2020-03-30T15:54:55+00:00 URL: https://externals.io/message/109415#109456 · In reply to: #109450 @Dan Ackroyd > That's an aesthetic choice, which not everyone will agree with. > Yes, I freely state that in the RFC. Everyone is free to vote how they like. > > "There shouldn't be any backwards incompatible changes" > > It apparently breaks 25 tests that compare the output of var_export > with an expected version. Userland users who have similar tests will > experience similar breaks. > > A test that compares var_export output is a pretty broken test, in my opinion. This is similar to a test that would use the value of a constant to test that the constant works. You're testing PHP code you shouldn't care if it uses the long form array construct or short form. Just test that it gives you an array. With that said, I will update the RFC to make note of these tests and I will fix them should the RFC be voted in. > Is there any reason to do this change other than aesthetic choice? > > Just because it is aesthetic is not actually an argument against. Why wouldn't you want to improve the aesthetics of PHP? Is it only an aesthetic choice, however? Not entirely. I also state that it is easier to read and type (saves space) and is more inline with JSON notation which is a lot more ubiquitous these days. These are all pros. I see no cons in that change. --- ## #109457 — Sherif Ramadan — 2020-03-30T15:56:31+00:00 URL: https://externals.io/message/109415#109457 · In reply to: #109452 @Sara Golemon > Ditto Danack's question, adding: "Then why not use brick/varexporter?" > > -Sara > I punt the question back to you and ask why not use PHP? --- ## #109458 — Derick Rethans — 2020-03-30T16:01:13+00:00 URL: https://externals.io/message/109415#109458 · In reply to: #109456 >@Dan Ackroyd > > > […] >Just because it is aesthetic is not actually an argument against. Why >wouldn't you want to improve the aesthetics of PHP? Is it only an >aesthetic >choice, however? I added this function to be able to create a PHP variable structure expressed as PHP code, so that the PHP parser can construct it back into variable structure. Aesthetics are irrelevant for a computer. This change does not improve anything and only breaks compatibility. Bad idea. cheers, Derick --- ## #109459 — Sherif Ramadan — 2020-03-30T16:07:34+00:00 URL: https://externals.io/message/109415#109459 · In reply to: #109458 > > > Aesthetics are irrelevant for a computer. > > This change does not improve anything and only breaks compatibility. Bad > idea. > > I beg to differ. While code may be meant for execution by a machine it is actually intended for human consumption. Aesthetics matter to a human reading the code. --- ## #109460 — Benjamin Morel — 2020-03-30T16:38:44+00:00 URL: https://externals.io/message/109415#109460 · In reply to: #109454 > > If "they" don't care about syntax, then why do you? Sorry I was unclear. I was reacting to the argument about broken tests in php-src. I meant: they don't have *expectations* about the syntax, but they'll most likely want to be able to read it. — Benjamin --- ## #109461 — Sara Golemon — 2020-03-30T17:18:51+00:00 URL: https://externals.io/message/109415#109461 · In reply to: #109457 On Mon, Mar 30, 2020 at 10:56 AM Sherif Ramadan wrote: > @Sara Golemon > > > > […] > > I punt the question back to you and ask why not use PHP? > > Simple. Because an implementation in script code is more agile, more accessible, and more maintainable in the long term. It's better in every way except default availability. Considering the *1 line* required to make it available in a project, this is not a compelling reason. Conversely, avoiding unnecessary breakage of existing code over a matter of aesthetics IS a compelling reason. Now, will you answer my question? -Sara --- ## #109462 — Sherif Ramadan — 2020-03-30T17:32:09+00:00 URL: https://externals.io/message/109415#109462 · In reply to: #109461 > On Mon, Mar 30, 2020 at 10:56 AM Sherif Ramadan > wrote: > > > […] > accessible, and more maintainable in the long term. It's better in every > way except default availability. Considering the *1 line* required to make > it available in a project, this is not a compelling reason. Conversely, > avoiding unnecessary breakage of existing code over a matter of aesthetics > IS a compelling reason. > > Now, will you answer my question? > Simple. Because an implement in php-src is more available, does not appear to have a lot of maintenance overhead, is easy to implement and it's better in every way. Considering the 6 lines of code required to make this change available to everyone. Given that code is meant for human consumption and given that aesthetics play a big role in code readability I would say that conversely doing it IS a compelling reason. Apart from the 25 phpt tests that (in my opinion) are testing the wrong thing in the first place, what major projects do you know of that would break as a result of this change? And I'm not talking about more tests that test the output of `var_export()` because that's a breakage I can live with. If you were using the function as intended you would only be testing that it gives you back valid PHP code and not trying to test its literal output. > -Sara --- ## #109463 — Sara Golemon — 2020-03-30T17:32:37+00:00 URL: https://externals.io/message/109415#109463 · In reply to: #109460 On Mon, Mar 30, 2020 at 11:39 AM Benjamin Morel wrote: > If "they" don't care about syntax, then why do you? > > > Sorry I was unclear. I was reacting to the argument about broken tests in > php-src. > I meant: they don't have *expectations* about the syntax, but they'll most > likely want to be able to read it. > > And we circle back to the current syntax being perfectly readable. We could keep this up all quarantine... In a more practical example, https://github.com/php/web-php/blob/master/include/releases.inc is an example of a `var_export()` generated file that lives in the wild and is regularly updated. I would say it's fairly readable, HOWEVER I WOULD AGREE WITH YOU that it would be MORE readable using short array syntax and skipping the index numbers. In fact, I had exactly this thought nearly 3 years ago when I started touching this file regularly. (plus the fact that the structure of this array is kinda gross). You'll note though, that I'm not championing making this file more reasonable. Because it doesn't matter. Because accidental damage to existing code isn't worth a minor bit of aesthetics by a file which is primarily read by machines. If it really mattered to me in any meaningful way, I'd write the dozen or so lines of script needed to output in a "pretty" way. Or I'd go google and find brick/varexporter. Lastly, there are at least six RMs at any given moment working on PHP's release. Can you imagine if we were updating this file using different versions? The git churn would be horrific. Do not want. If we really wanted "pretty var_export", then there'd be no real choice BUT to use a library script to do the serializing. -Sara --- ## #109465 — Sara Golemon — 2020-03-30T17:36:37+00:00 URL: https://externals.io/message/109415#109465 · In reply to: #109462 On Mon, Mar 30, 2020 at 12:32 PM Sherif Ramadan wrote: > Now, will you answer my question? > > […] > > Simple. > Wrong. It's complex as this thread proves. Opinions are not in alignment making it non-simple. > Because an implement in php-src is more available, > Wrong. It's got availability FOR THOSE ON THE LATEST VERSION. It is LESS available for those on older versions. > does not appear to have a lot of maintenance overhead, > Neither does brick/varexporter, this point is irrelevant. > is easy to implement > The format you want is already implemented. Done is easier than TODO. > and it's better in every way. > Wrong. Please consider reading my earlier reply. > Given that code is meant for human consumption > Wrong. It is meant for machine consumption. > I would say that conversely doing it IS a compelling reason. > > Wrong due to every part of your statement being wrong. All the best. -Sara --- ## #109466 — Chase Peeler — 2020-03-30T17:37:51+00:00 URL: https://externals.io/message/109415#109466 · In reply to: #109463 > On Mon, Mar 30, 2020 at 11:39 AM Benjamin Morel > wrote: > > > […] > most > > […] > could keep this up all quarantine... > > In a more practical example, > https://github.com/php/web-php/blob/master/include/releases.inc is an > example of a `var_export()` generated file that lives in the wild and is > regularly updated. > > I would say it's fairly readable, HOWEVER I WOULD AGREE WITH YOU that it > would be MORE readable using short array syntax and skipping the index > numbers. In fact, I had exactly this thought nearly 3 years ago when I > started touching this file regularly. (plus the fact that the structure of > this array is kinda gross). > > You'll note though, that I'm not championing making this file more > reasonable. Because it doesn't matter. Because accidental damage to > existing code isn't worth a minor bit of aesthetics by a file which is > primarily read by machines. If it really mattered to me in any meaningful > way, I'd write the dozen or so lines of script needed to output in a > "pretty" way. Or I'd go google and find brick/varexporter. > > Lastly, there are at least six RMs at any given moment working on PHP's > release. Can you imagine if we were updating this file using different > versions? The git churn would be horrific. Do not want. If we really > wanted "pretty var_export", then there'd be no real choice BUT to use a > library script to do the serializing. > > -Sara > I'm with Sara on this, which shouldn't be a big surprise. 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. -- Chase Peeler chasepeeler@gmail.com --- ## #109467 — Derick Rethans — 2020-03-30T17:42:14+00:00 URL: https://externals.io/message/109415#109467 · In reply to: #109466 > 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. And then you'd have to maintain two behaviours, and a flag, and their test files. cheers, Derick --- ## #109468 — Sara Golemon — 2020-03-30T17:42:44+00:00 URL: https://externals.io/message/109415#109468 · In reply to: #109466 > 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. -Sara -Sara --- ## #109469 — Derick Rethans — 2020-03-30T17:45:51+00:00 URL: https://externals.io/message/109415#109469 · In reply to: #109462 > Given that code is meant for human consumption I have already told you that the output of this function was never meant for human consumption. It was originally added to aid in caching of larger complicated data structure through the likes of apc's opcode cache. 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 --- ## #109472 — Morgan Breden — 2020-03-30T20:40:57+00:00 URL: https://externals.io/message/109415#109472 · In reply to: #109469 > I have already told you that the output of this function was never meant > for human consumption. > It was originally added to aid in caching of larger complicated data > structure through the likes of apc's opcode cache. It is sometimes used for human consumption now, though. For example, my team often uses it to generate database seeders from staging environments. With respect, I don't think "I didn't intend this to be used in the way it is now used" is a compelling argument against improving something, rather it's an argument *for* improvement in my eyes. Other arguments here not withstanding. > > > > […] > > I have already told you that the output of this function was never meant > for human consumption. > > It was originally added to aid in caching of larger complicated data > structure through the likes of apc's opcode cache. > > 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 --- ## #109524 — Andrea Faulds — 2020-04-03T21:16:17+00:00 URL: https://externals.io/message/109415#109524 · In reply to: #109468 Hey Sara, Sara Golemon wrote: > > > > […] > `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 --- Next page: https://externals.io/message/109415.md?page=2