On Sat, Jun 4, 2011 at 4:52 AM, David Zülke <david.zue...@bitextender.com> wrote: > Yes, I know. Then why are you and others demanding that the resulting syntax > be fully compatible with JSON so it could be parsed by other JSON parsers? > That makes no sense at all. A file with just ["foo"] in it won't be > interpreted by PHP; you need at least <?php ?> wrappers and a semicolon, and > then you can't just throw it at another JSON parser anymore.
I don't think anyone was asking for this. I and others have been misunderstood on this point, and there seems to be some confusion about how "other systems" came into this discussion. The desire is to be able to copy/paste things back and forth and make it work with only minor tweaks. For example, when debugging a query against a system that uses JSON as the standard for communication, it is invaluable to be able to copy the problem query from your code, paste it into whatever administrative interface you have, and replace any variable rvalues with constants. After the problem has been worked out, you can copy from the admin interface, paste back to the code, and restore any variables. If PHP handles an object/array syntax that is roughly similar to JSON, this becomes easy. The more different the syntaxes are, the more painful this becomes, until eventually it really isn't an option at all (which is where we are now). An example perhaps more familiar to most of us is debugging complex regular expressions. Imagine how impossible this would be if there were no way to copy the regular expression from your code to a web based debugger without rewriting it? Also, consider how frustrating it is sometimes when you paste it back and it still doesn't work, because you forgot to escape your slashes. The more manual translation the programmer has to do, the more impractical these sorts of tools become for debugging. I know a lot of people on this list have strong feelings about whether other systems should be using JSON as a query language/transfer encoding/whatever else; but, the fact is that they do. These systems are growing more popular, and not going to disappear any time soon, which means that like it or not, developers will need tools and languages that simplify the development and debugging process. This RFC should be considered (among other things) in terms of whether it is helpful to developers using these systems, but not in terms of whether anyone wishes these systems would go away (because they won't). John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
