Comments to the JSON related proposals

Kris Zyp kriszyp at
Sun Aug 19 21:45:36 PDT 2007

> where a filter might be used which have quite different needs: in the case 
> of temporary/internal keys scattered in an object, it might be easier to 
> just specify those keys and be done with it
Specifying temporary/internal keys on serialization is generally a poor 
approach, but rather the temporal natural of keys should be a part of the 
definition of object behavoir/type. I believe ES4 should have a property 
modifier "transient" (like Java), and then the properties would be defined 
as temporary in the class definition and the serialization should 
automatically omit transient properties. To illustrate this further, if one 
were to write an alternate serialization method toXMLString and the object 
that included properties that were temporary was serialized, it should not 
be necessary to respecify which properties were temporary for the 
toXMLString call. Rather that could be defined when writing a the class for 
the object:
class MyClass{
 int permanent;
 transient int exclude,these,keys;
> Since JSON is a serialization format, encoding and decoding should be 
> fully reversible - or else you risk running into unexpected subtle errors 
> which make JSON related code more fragile than necessary.
It seems to me that JSON is not even close to attempting to be reversible 
for the general JavaScript objects, but only for simple data structures. The 
list of things that JSON can not serialize in ES3 (and then deserialize to 
original state) includes circular references, multiple references to single 
objects, dates, functions, objects with prototypes, arrays with strings 
keyed properties, and so on. In ES4 the gap grows even wider with typed 
objects and namespaced keys (IMHO the namespaced keyed objects of ES4 almost 
feels to me conceptually incompatible to string keyed objects of JSON).


More information about the Es4-discuss mailing list