- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 05 Nov 2012 14:40:12 -0500
- To: Alex Russell <slightlyoff@google.com>
- CC: public-web-security@w3.org, Cameron McCormack <cam@mcc.id.au>
On 11/5/12 1:08 PM, Alex Russell wrote: > If you want to allow writing to these things sometimes but not > others while making it look like normal ES semantics, things are a > bit complicated because of strict mode. > > Why strict mode? I'm not sure that matters. WebIDL lets you define an attribute as either writable or readonly. If it's readonly, attempts to set are ignored in non-strict mode and throw in strict mode. If it's writable, attempts to set call an IDL setter, which is in theory language-independent and thus has no concept of strict mode. Note that a pure-JS implementation would have the same problem, by the way; the only way I know of to implement something like this in JS is to have two prototypes, with the property having no setter on one and a setter on the other, and have your objects inherit from the right prototype. Unless I'm missing something. > Cameron: my view here is that the document.securityPolicy would be > defined as a getter that returns a Proxy (in ES6 terms) and that the > proxy would enforce the read-only invariants. It would be proxying for a > "naive" SecurityPolicy object. Wait. Why would we want a proxy there instead of just an object? That seems like proxy-happiness at the expense of other things... What does using a proxy instead of a separate interface for writable security policies buy you, exactly? What it loses you is basic things like sane instanceof behavior, afaict. > There is no way to return a JS array that points directly into the > stored state of an object in WebIDL right now. Again, because we > want to allow implementing the DOM in a language other than JS while > remaining sane. > > Sane for whom? ;-) The implementor. ;) > The goal of language fidelity isn't some abstract notion. Sure it is. It means different things to different people. A concrete notion would be an actual description of the behavior. > That said, WebIDL can do magic. Within reason, sure. There have been proposals that were shot down because they're no implementable in ES. > If it's doing magic, it should do magic > on behalf of JS users today, even when JS isn't sane enough to explain > it all. Sure, as long as there's an actual spec, not handwaving. -Boris
Received on Monday, 5 November 2012 19:40:44 UTC