defineProperty/getProperty design sketch

Brendan Eich brendan at mozilla.org
Wed Apr 23 15:35:43 PDT 2008


On Apr 23, 2008, at 8:36 AM, John Resig wrote:
> I'm confused as to why an API is being proposed which clashes with  
> existing JavaScript-style APIs. The one case that I had seen  
> previously, at least related to the implementation within Mozilla,  
> is that it would look something like:
>
>   Object.defineProperty(obj, name, value,
>     Object.NOT_WRITABLE | Object.NOT_ITERABLE | Object.NOT_DELETABLE)
>
> Which makes much more sense than the proposal (not forcing the user  
> to create temporary objects just to insert values).

I agree it's better to have minimal-cost APIs that do not require  
object allocations (or fancy optimizations to avoid allocations).

One overloaded API with an object parameter with too many degrees of  
freedom is also undesirable compared to targeted APIs, if the names  
and differences in use-case among the targeted set clearly  
distinguish them from one another.

Another point (and I've said this to Allen already): I think browser  
vendors who have had to implement __defineGetter__, __defineSetter__,  
__lookupGetter__, and __lookupSetter__ would rather either  
standardize those as-is, or standardize Object.defineGetter, etc.,  
counterparts to which the Object.prototype methods could forward.

The clarity of object initialisers for flags is better, but only  
slightly. Per Neil Mix's suggestion (in his March 13, 2008 message to  
es4-discuss), the Object "static constants" would be named to avoid  
double-negative English hazards: WRITABLE, ENUMERABLE, REMOVABLE.

A slight improvement to bias for conciseness in the common case, if  
it is the common case, would invert the sense of WRITABLE and require  
a READONLY flag for consts. An inverted sense for REMOVABLE would be  
named PERMANENT, if that is likely to be the exceptional case (is it?).

This brings up the point Tucker made recently: READONLY with  
REMOVABLE is pointless. The Wheat prototype-based programming  
language found its initially-Unix-like mode bits had fewer sane than  
total linear combinations, too.

StrawName   | READONLY  ENUMERABLE   REMOVABLE
------------+---------------------------------
FIXTURE     |        0           0           0
PROTOTYPE   |        0           0           1
VAR         |        0           1           0
PROP        |        0           1           1
CONST       |        1           0           0
N/A         |        1           0           1
ENUM        |        1           1           0
N/A         |        1           1           1

The StrawName column contains some proposed names for the  
combinations or N/A where the combination is nonsense. These flag-bit- 
combination names do not always add clarity compared to |'ed flag-bit  
manifest constant names, IMHO.

Comments? We need to come to agreement here quickly, for both ES3.1  
and ES4 to hang together.

/be



More information about the Es4-discuss mailing list