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={tempKey:1,myConst:2,hidden:3};
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) ->
obj.setAttributes("hidden",Properties.DONTENUM);
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))
..serialization...
I would love this, but I am guessing that most would think this a little bit
too much power for users...
Kris
----- Original Message -----
From: "Simon Bünzli" <[EMAIL PROTECTED]>
To: "Kris Zyp" <[EMAIL PROTECTED]>
Cc: "Brendan Eich" <[EMAIL PROTECTED]>; <[email protected]>
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
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
