You are right, Allen. I didn't mean to modify JSON itself. And as Lasse Reichstein said above, JSON is not controled by this group at all.
I am just thinking we need a way to serialize/unserialize a js object with circular reference to itself. Obviously JSON can not handle it currently. It might be Object.serialize/Object.unserialize or JSON.parseJSONP or what ever. I'm OK with any form of APIs. 在 2012年3月6日 上午12:53，Allen Wirfs-Brock <[email protected]>写道： > 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 <[email protected]> > >> 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 <[email protected]> wrote: >> >>> On 5 March 2012 13:35, 程劭非 <[email protected]> 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 >>> [email protected] >>> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
