Expressing that a property is non-deletable (was: Function identity of non-configurable accessors)

Tom Van Cutsem at
Wed Dec 19 05:54:53 PST 2012

2012/12/18 Mark S. Miller <erights at>

> I see no reason why this needs to be a reflected property. As to
> whether it is an exotic internal property or just prose, that is a
> specification expository issue for which I defer to Allen. But the
> spec only needs such extra state for the exotic global object. There's
> nothing general about it.

The deeper issue pointed out by David here, I think, is that the triplet
{enumerable,writable,configurable} does not cover the entire possible space
of what one might want to express about the behavior of a property.

If I understand correctly, the concrete case here is a property that cannot
be deleted (which is normally expressed as configurable:false), but which
should still remain configurable.

I think it is unpractical and unwieldy to bake new attributes in to the ES
spec for every use case that pops up.

However, in the context of proxies, we have previously talked about the
usefulness of allowing handlers to accept custom attributes in their
defineProperty trap and return custom attributes from their
getOwnPropertyDescriptor trap.

By analogy, it might make sense for WebIDL-specified host objects to return
additional custom attributes to describe the behavior of special properties
that cannot be captured by {enumerable,configurable,writable}.

The remaining "problem", of course, is that there is no standard semantics
for custom attributes. As mentioned by Allen in another thread, the only
solution here is for an exotic object to properly document its interface,
including what meaning it ascribes to any custom attributes it wishes to
report or accept.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list