defineProperty/getProperty design sketch

Mark S. Miller erights at
Wed Apr 23 20:44:50 PDT 2008

Allen and Crock, Check out the bottom of
Your posts are still not showing up on es4-discuss; I'm not sure why.

Everyone else, if you want to see the missing posts, please check out

On Wed, Apr 23, 2008 at 7:09 PM, Allen Wirfs-Brock
<Allen.Wirfs-Brock at> wrote:
> I think our differences are largely syntactic sugar, but that sugar can be important for usability.


> If I interpret you comments correctly you are proposing to only have the defineProperties form with the multi-descriptor.  Is that correct?


> In that case my first example would look like:
> Object.defineProperties(Array.prototype,{some: {enumerable:false}});
> Rather than:
> Object.defineProperty(Array.prototype, {name: "some", enumerable: false});


> And modifying multiple properties would look like:
> Object.defineProperties(Array.prototype,{
>     some: {enumerable:false},
>     map: {enumerable:false},
>     foreach: {enumerable:false}});
> rather than: [...]


> I could go either way, for a single property the extra level of { } seems unnecessary but getting rid of the quoted name is nice.

Notationally, an extra {} is cheaper.

> My bigger concern is what your intend to do about the name property of individual descriptors.

Kill it.

> Do you ever have one, particularly for a descriptor returned from getProperty/getProperties?


> Or is an outer multidescriptor always used to name a descriptor?


>  Is it a good idea to allow for loose descriptors without an associated name?

I don't see why not.

> Regarding:  Object.defineProperties(obj, {x: {value: 0}, y: {value: 0}, {pi: {writable: false}});
> Since you assert that "all unenumerated attributes of an explicitly defined property should default to false" then it would seem that you should have said:
> Object.defineProperties(obj, {x: {value: 0, writable: true }, y: {value: 0, writable: true }, {pi: {writable: false}});

Depends on what the intent was. Given the intent you imply, then yes.
If "pi" is known to be a new property, then "{pi: {value: 3.14159}}"
would be sufficient.

> This is part of the reason, that I distinguished between a descriptor containing "value:" and a descriptor containing "method:".  My thinking was that the "normal" writability of an "instance variable" property would be true while for a property used as a "method" the normal writability would be false.  I wanted to make this normal usage the default.  In addition, in this semi-declarative style of object definition, I think it is a good idea to allow the user  to be explicit about which properties are intended to be variables and which are intended to be properties.

You mean "methods" rather than "properties" at the end above?

If the only operational effect of distinguishing value: vs method: is
these defaults, I don't think the benefit pays for the additional
complexity. I'd rather adopt the "deny by default" common wisdom. Now
that we're consistently phrasing attributes in terms of the things
they allow, having them default to false, i.e., deny, is easy to

> BTW, this may be an issue for the getter/setter specification but it's not clear to me what the interpretation of the ReadOnly (ie writable) attribute should be for getter/setter properties. Should it indicate whether a getter is defined or does it control whether or not the property can be redefined to not be a getter/setter. To consistently add getters/setters and allow for their transparent use do we actually need a new attribute which means not redefinable?

A good question. Perhaps "deletable" should be subsumed by "redefinable"?

> Bottom line, I think your multi-descriptor form could grow on me.

Glad to hear it! Though I'll try to avoid visualizing a
multiDescriptor growing on you ;).

> I'm concerned about not having a name property in a naked descriptor.

Just use a singleton multiDescriptor instead to fully describe a
single property.

> I like distinguishing intent about methods and instance variable property usage and that may require that the default interpretation of "unenumerated properties" needs to be situational.

I wish to minimize situational caveats in the spec. Let's keep it simple.


More information about the Es4-discuss mailing list