Possible Loophole (was: Proposal: Property fixing)

Mark S. Miller erights at google.com
Fri Jun 17 14:32:13 PDT 2011

On Fri, Jun 17, 2011 at 2:23 PM, David Bruant <david.bruant at labri.fr> wrote:

> **
> 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>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.

The constraints enforced by {writable:false, configurable:false} are
universal: on such a property, value must always produce the SaveValue. If
what you're saying is that {writable:false, configurable:true} enforces no
guarantees, I agree.

> 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,
> Object.getOwnPropertyDescriptor(document.getElementsByTagName('*'),
> 'length') could return {value:12, configurable:true, enumerable:false}.

Correct, because it's configurable.

>   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.

Yes. I am leaning in that direction. Thanks.

> David

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

More information about the es-discuss mailing list