defineProperty/getProperty design sketch

Mark S. Miller erights at
Wed Apr 23 21:07:41 PDT 2008

On Wed, Apr 23, 2008 at 2:37 PM, Douglas Crockford
<douglas at> wrote:
> I am very encouraged by this. We are clearly on the right path here. We are
>  exposing essential mechanisms with a light and expressive interface. Most new
>  feature proposals barely meet the standard of usefulness. This one meets a much
>  higher standard, that of necessity.
>  There are just the details to get right. In comparing Allen's sketch and Mark's
>  counter sketch, it seems to me that either would work.
>  I think I refer Allen's. I like the symmetry of the structure shared between
>  Object.setProperty and Object.getProperty.

The other proposal has a similar symmetry between defineProperties and
getProperties. Both traffic only in multiDescriptors.

> I like the finer granularity of -y()
>  rather than -ies() because it is clearer what happens if a request fails.
>  Object.setProperties can set many attributes of many properties. If setting of a
>  single attribute fails, in what state is the object left? No changes, partial
>  changes, all possible changes?

Great question! No change. As a result, the -ies() forms provide
functionality not practically achievable with the -y() form.

>  In the case where it fails, I prefer return false to throw. It doesn't seem
>  extraordinary enough to warrant an exception.

Defensive code would then always have to check the return value and
throw if it's false. As Allen's own expository examples show, and as a
long history of bad Unix/C programs show, programmers will often
forget to do this, rendering their code vulnerable to confusion
attacks. Once something goes wrong, especially if an attacker can
induce the failure, execution must not innocently proceed on normal
flow-of-control paths whose assumptions are violated.

>  I want to understand why Object.beget needs more than one parameter.

I think I get it:

    Object.beget(foo, {x: 3, y: 4})

would be like

    {__proto__: foo, x: 3, y: 4}


More information about the Es4-discuss mailing list