Comments to the JSON related proposals

Brendan Eich brendan at mozilla.org
Sun Aug 19 23:07:27 PDT 2007


Hey Kris, Simon; a few comments:

On Aug 19, 2007, at 9:45 PM, Kris Zyp wrote:

>> 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

Who said anything about 'class'? :-)

JSON is and remains class-less, serializing Object and Array data  
definitions, whether created by object and array initialisers or not.  
So transient doesn't apply to array, but given the ongoing lack of  
requirement for class-based programming, and the low odds of that  
style taking over for JS apps producing and consuming JSON, the  
question arises: How would ad-hoc transient properties be set or  
initialized in any old object?

> 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).

Superset, not incompatible. Even in ES3 there are types that don't  
exist in JSON, as well as other kinds of structures that can't be  
serialized, as you note. JSON is not going to change much, AFAICT.

The challenge for any language trying to provide safe and usable APIs  
to produce and consume it is what to do when the input to the  
serializer can't be represented. Dropping a namespace qualifier is  
bad because it will lead to local name collisions (Murphy says). In  
general, silently dropping names and types that don't fit in JSON  
seems like deadly silence, not the golden kind.

/be





More information about the Es4-discuss mailing list