On Fri, Jun 17, 2011 at 2:23 PM, David Bruant <[email protected]> wrote:
> ** > Le 17/06/2011 22:20, Mark S. Miller a écrit : > > On Fri, Jun 17, 2011 at 11:56 AM, David Bruant <[email protected]>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 > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
