2011/6/2 Sanford Whiteman <swhitemanlistens-softw...@cypressintegrated.com>
> > I don't think anyone cares about JSON for the sake of being perfect
> > JSON, I didn't intend to give that impression.
>
> Then you should stop saying "pure JSON" and "true JSON" constantly!
>
> > I'm only hoping for something that generally works on par with all
> > the other JSON parsers in the world.
>
> OK, that trashes your example, where values were set based on the
> result of a PHP function. There is no "par" for JSON parsers running
> methods _at creation time_, within the server (author) context.
> Setting vars to the return value of a function is something we take
> for granted in real languages, but it cannot happen within what a
> knowledgeable person would call "JSON."
>
> > Yes, JSON is a very specific encoding, but when a developer writes
> > something "jsony", what they mean is "an object/array with the
> > following structure/values", because that is what the encoding
> > really represents.
>
> Not Javascript developers. Maybe jQiddies think that
>
> {'$gt': strtotime('-1 day')}
>
> is "JSONy" more than it is "JS objecty"?
>
> This is like starting from "Wouldn't inline CSVs be great for creating
> arrays?" and drifting to "I mean, not like with that comma-escaping
> stuff, and, uh, newlines would be allowed in the middle of a record,
> and you'd have to allow create-time interpolation of function calls.
> You know, CSVy!"
>
> Only thing I might generously refer to as being "JSONy," while
> provably not being valid JSON, is a string that conforms in every way
> _except_ for using single quotes -- everywhere that doubles are
> required -- instead of using doubles. Anything else is someone's
> mangled "JankySON" or just not JSON.
>
> -- S.
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
-1 to the RFC.
+1 to => against : if the array short syntax it's finally implemented.
I, being a lazy programmer, don't want anymore new syntax to do the same
thing. I don't care if it a) saves me houndred of kaystrokes in the
definition of arrays, or if b) it's more familiar with
_put_your_favorite_syntax_here_ because:
a) I prefer the simple way of _this_ is done _this_ way against _this_ is
done _this_ way or _this_another_ way or _this_yet_another_ way.
b) When another new fancy tendency of encoding appear I don't want to see it
in the core, because another one will appear in the future and then we will
be in the same point, stacking stuff forever or talking about deprecating
the old and breaking BC.
My point is: I'm for implementing something that can't be done currently in
PHP, but against for implementing another way of doing the same.
