defineProperty/getProperty design sketch

Jon Zeppieri jaz at bu.edu
Wed Apr 23 19:07:19 PDT 2008


On 4/23/08, Mark S. Miller <erights at google.com> wrote:
> >
> > Use case: modify attributes of an existing property.
> >
> > Descriptor = { name: string, [, writable: boolean] [, enumerable: boolean]
> [, deletable: boolean]}
> Without the "name: string" part, since that comes from the multiDescriptor.
>
> >
> >
> >
> >
> >
> >
> > If obj has a local property whose name is the value of the name element of
> the descriptor set the attributes of the property according to the values of
> the writable, enumerable, and deletable elements of the descriptor.  Fail if
> the property does not exist  (or add fixed/frozen attribute)
> If the property does not yet exist, then all unenumerated attributes of an
> explicitly defined property should default to false. If the property already
> exists, then unenumerated attributes should default to their existing value.
>


Are there compelling use cases for modifying the writable and
deletable attributes of a property, post-definition?  If a
non-writable property can be made writable, then all properties are
writable.  Some are just more annoying to write to than others.  Does
Object.freeze have an irreversible effect on the deletable attribute
of the object's properties?  (Same question for Object.seal /
writable...)

Even if the answer is yes, this still isn't sufficient to express the
ES4 notion of a fixture, since an entire object is frozen/sealed,
whereas in ES4:

     var o = {var x: 10, y: 20};

... my understanding is that o.x cannot be deleted by any mechanism,
since part of the intention behind fixtures is to allow early binding.

Maybe the idea is that an attempt to make o.x deletable would simply
fail in ES4.  But since Brendan noted that initializers should be
considered sugar for imperative code, we should be able to describe
the desugaring -- preferably as a plain source-to-source
transformation that doesn't require reference to some, say,
[[SetAttribute]] meta-method.  That would require an imperative way of
defining a fixture (in the ES4 sense).  Maybe that could be done as an
extension to what's being proposed for ES3.1, rather than as part of
it, but I don't really know what that would look like.

-Jon



More information about the Es4-discuss mailing list