Comments to the JSON related proposals

Kris Zyp kriszyp at
Mon Aug 20 10:33:23 PDT 2007

What if instead of only exposing property enumerability we exposed all the 
property attributes that were previously hidden in ES3 (and included 
"transient" as one of those properties)?
obj.setAttributes("tempKey",Properties.TRANSIENT); // define transient 
without a class
obj.setAttribute("myConst",Properties.READONLY); // we could define 
constants without classes
and get rid of propertyIsEnumerable:
obj.propertyIsEnumerable("hidden",false) -> 

The toJSONString for objects could then include a check (as well as any 
other serialization schemes that users might write):
if (!(obj.getAttributes(key) & Properties.TRANSIENT))

I would love this, but I am guessing that most would think this a little bit 
too much power for users...

----- Original Message ----- 
From: "Simon Bünzli" <zeniko at>
To: "Kris Zyp" <kriszyp at>
Cc: "Brendan Eich" <brendan at>; <es4-discuss at>
Sent: Monday, August 20, 2007 9:56 AM
Subject: Re: Comments to the JSON related proposals

> Kris Zyp schrieb am 20.08.07 16:57:
>>> question arises: How would ad-hoc transient properties be set or 
>>> initialized in any old object?
>> With classes being available, why not provide a pathway for developers to 
>> define transience correctly in proper OO manner that would be 
>> serialization method agnostic, rather than adding a blacklisted array 
>> parameter to toJSONString, which IMHO is very poor and shortsighted way 
>> of defining transient/temporary keys?
> What you suggest sounds like a good enhancement to what I've proposed (in 
> fact, I hadn't considered ECMAScript as an OOL at all). I'd still keep the 
> blacklist though for the following reasons:
> * Legacy-code (i.e. ECMAScript 3 code) may want to take advantage of 
> toJSONString without converting all expando'd objects to classes.
> * Having to set transciency for temporary/internal attributes may result 
> in code in places where it doesn't really matter or even belong at all.
> E.g. in our use case (Firefox' SessionStore service), JSON export has been 
> modularly added and takes advantage of the fact that our internal data 
> structures nicely map into JSON. Inside the core service, the temporary 
> keys aren't transient per se - they just shouldn't be serialized for our 
> JSON API. For different API, we might even to serialize a different set of 
> keys, which would not be easily possible with setting transciency in the 
> core code. So either we have a blacklist (or a less efficient way for 
> filtering out keys), or we'd have to clone our object first which won't be 
> more efficient than just doing the JSON conversion ourselves in 
> JavaScript.
> * Even for code written against ECMAScript 4, you'd force a strict class 
> model where expando'd objects would be sufficient (not everybody likes the 
> rigidity of an OO class model - especially for RAD):
> var obj = { some: 1, key: "text" };
> obj.expandoed = [-1, -2, -3];
> // potentially lots and lots of unrelated code...
> obj.toJSONString(); // how to temporarily ignore some keys here?
> ~sb 

More information about the Es4-discuss mailing list