Oops, it was a mistake. I replied to all rather than to the list, so I
apologize because I wanted to give my opinion in general and not to reply to
anybody in particular.
Regards.
2011/6/2 John Crenshaw <johncrens...@priacta.com>
> There’s no need to be rude. If you can’t make your point without attacking
> people, then you need a better argument.
>
>
>
> “JSON” in this case just means a simple object notation using {, [, and :.
> You know that. Yes, we’re all abusing the term, just like we all abuse
> “AJAX”, regardless of the fact that almost nobody ACTUALLY uses XML as the
> transfer encoding. Who cares? “JSON” is the best word available. Unless you
> can suggest a better word to differentiate this format from the others (one
> that isn’t designed to insult anyone who disagrees with you) stop fussing
> about it.
>
>
>
> John Crenshaw
>
> Priacta, Inc.
>
>
>
> *From:* Eloy Bote Falcon [mailto:eloyb...@gmail.com]
> *Sent:* Thursday, June 02, 2011 3:58 AM
> *To:* Sanford Whiteman
> *Cc:* John Crenshaw; PHP internals
>
> *Subject:* Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
>
>
>
>
>
> 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.
>
