- From: Cameron McCormack <cam@mcc.id.au>
- Date: Tue, 06 Nov 2012 09:16:47 +1100
- To: Alex Russell <slightlyoff@google.com>
- CC: Boris Zbarsky <bzbarsky@mit.edu>, public-web-security@w3.org
Hi, Boris Zbarsky: > Your best bet is to actually use separate interfaces for the readonly > and writable versions at that point, unless WebIDL is somehow changed > to allow this. Alex Russell: > +heycam > > 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. Sorry for not having the context: do you have a pointer to where having writable and non-writable securityPolicy attributes is needed? Is it something that needs to change dynamically on the one object, or at object creation time you know whether securityPolicy is writable or not? If it's the latter, then I think either Boris' suggestion of having two interfaces, and stating in prose which one is implemented on Document, would be OK. I think it'd be fine too to just make it not readonly in the IDL and for there to be a prose hook to do all the right throwing-or-ignoring things that you would normally get from assigning to an accessor property without a setter.
Received on Monday, 5 November 2012 22:17:28 UTC