Let's get back to some key mainly non-technical points. JSON is a data interchange format that was created to support data interchange between heterogeneous systems, not just JavaScript.
TC39 does not define the actual JSON encoding format. If we extend it, it is no longer JSON. There are many domain specific applications of the JSON format. These typically make use of a data schema defined (either formally or informally) over the JSON format. One domain specific application is serialization (for storage or transport) of arbitrary JavaScript object graphs. Many of us have defined either special case or general purpose JSON schemas for doing this. Many people have also done so for other languages. Designing a JS object graph serialization schema for JSON is not the same thing as extending JSON. If anybody thinks they have the ultimate JS serialization schema, publish it as a library and try to get people to use it. If it gets broad adoption and there is a major benefit that would come from it being an integral part of the language standard, come on back and talk to TC-39. Finally, I'm not saying there are no circumstances under which we should consider extending the ES JSON support. For example, I think we should consider adding JSON.parseJSONP as a function. JSONP has broad adoption and there would be a major security benefit from safely parsing it at the ES engine level. Allen On Mar 5, 2012, at 4:59 AM, 程劭非 wrote: > Thanks. I have mentioned it in my first email. :) > > 2012/3/5 Wes Garland <w...@page.ca> > Mozilla used to support something like this, it is being removed in Firefox > 12, but perhaps the implementation can give you ideas. > > https://developer.mozilla.org/en/Sharp_variables_in_JavaScript > > Wes > > On 5 March 2012 07:49, Andreas Rossberg <rossb...@google.com> wrote: > On 5 March 2012 13:35, 程劭非 <csf...@gmail.com> wrote: > > { > > a: path(/a2), // yes, path(/a2) is a object > > a2: {c: 1, d: path(../b/d)}, // no, path(/b) is a path itself you will > > get undefined here. > > b: path(/b2), //yes, path(/b2) is a object > > b2: {c: path(../a/c), d: 2}, // no path(../a) is a path itself you will > > get undefined here. > > } > > > > In general, I mean a path will never refer to a object specified by a path. > > Why? And anyway, what about: > > { > a: {c: 1, d: path(../b/d)}, > b: {c: path(../a/c), d: 2}, > } > > You still need deep dependency analysis. > > /Andreas > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > > > -- > Wesley W. Garland > Director, Product Development > PageMail, Inc. > +1 613 542 2787 x 102 > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
