Possible Loophole (was: Proposal: Property fixing)

David Bruant david.bruant at labri.fr
Fri Jun 17 14:23:39 PDT 2011

Le 17/06/2011 22:20, Mark S. Miller a écrit :
> On Fri, Jun 17, 2011 at 11:56 AM, David Bruant <david.bruant at labri.fr
> <mailto:david.bruant at labri.fr>> wrote:
>     For NodeLists proxy emulation, the "length" property cannot be
>     changed manually (as far as I know), so I'd say that its writable
>     has to be false (tell me if I'm wrong to think that).
> AFAIK, this is wrong. I am not aware of any requirement that so-called
> "writable" properties are actually writable.
Interesting. Basically, "writable" is semantic-less outside of normal
objects (and arrays, because they are in the spec). On host objects,
neither true nor false are enforcing any guarantee.
What about downgrading the "writable" attribute to an attribute specific
to normal objects (and arrays, because they work the same in the spec)?
non-native objects would, of course, be invited to use this attribute if
they want to provide similar semantics on their properties, but wouldn't
be forced to.
In this case,
'length') could return {value:12, configurable:true, enumerable:false}.

>     The "length" value can however change due to DOM tree
>     transformations. For this reason, configurable has to be true as
>     per Universal property constraints 1) a).
> #1a says only "either or both of the [[Writable]] and [[Configurable]]
> attributes must be true", which is the only constraint I would assume
> here.
> Hmmm. This suggests a loophole that might help out on some of the
> proxy cases we're concerned about. I know of no universal constraint
> that a proxy's handler could violate if it could 1) trap attempts to
> change the value of a writable non-configurable property, and 2) could
> respond by either setting the value as it likes or reporting a failed
> assignment. The handler must of course be prevented from changing any
> other attribute, except to change from writable to non-writable.
> AFAICT, this does not weaken any assumptions that are safe to assume
> regarding ES5.1 non-native objects.
Actually, since in the recent version of the strawman, the
defineProperty trap is actualy trapped even for fixed properties, I
think that what you're describing is happening already. Is it Tom?

> (As a further benefit, if we reconsider retroactive proxification for
> data binding, this would also allow the monitoring of non-configurable
> writable properties without needing per-property getters/setters.)
It would be the case also in the "trap all and enforce invariants in
relevant places" model.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110617/d6cf2574/attachment-0001.html>

More information about the es-discuss mailing list