I'm suddenly realizing that the actual need is, in many cases, specific to the development circumstances. When developing heavily against/with other systems that use JSON (like MongoDB, jQuery, various APIs, etc.) the value of true JSON is immeasurable, and anything that isn't JSON would look wrong in that code. On the other hand, something like ZendFramework may likely look better with something that is more internally consistent, (if it even uses the shorter syntax at all) since the primary emphasis of the code is PHP.
What if both syntaxes are allowed (both pure JSON, and the PHP-like => syntax)? Individual projects could gravitate to the format that makes the most sense on a case by case basis. John Crenshaw Priacta, Inc. -----Original Message----- From: Sean Coates [mailto:s...@seancoates.com] Sent: Wednesday, June 01, 2011 6:09 PM To: Anthony Ferrara Cc: PHP internals Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux) > Now, the only reason I would personally support the array shortcut is > if it was an implementation of JSON. I know that's not on the table > here I don't think anything is officially off the table, unless we forego discussion. My application is largely JSON-powered. We pass data from back- to front-end via JSON, we interact with MongoDB via the extension (which is an altered JSON-like protocol (arrays instead of objects), but would be a lot more fluent with actual objects-they're just too hard to make in current PHP), and we interface with ElasticSearch. The paste I linked earlier is our primary ElasticSearch query. The benefits of first-class JSON are important and wide-reaching; especially when interacting with systems like the ones I've mentioned. There's a huge amount of value in being able to copy JSON out of PHP and into e.g. CURL to make a query to ElasticSearch without worrying that I've accidentally nested one level too deep or shallow, or accidentally mistranslating my arrays into JSON. This is not about saving five characters every time I type array(), it's about making my systems all work together in a way that's a little less abstracted, and a lot less prone to error. S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
