Re: CSP 1.1 DOM design

On 11/5/12 2:40 PM, Boris Zbarsky wrote:
>>     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.  ;)

To be clear, this is not even a C++-specific problem.  If you were 
implementing SecurityPolicy in JS, and were exposing a way to get the 
list of policy URIs, would you hand out your internal list and let the 
caller mess with it, or would you hand out a copy?  This is both an 
interface and an implementation decision, because handing out the 
internal list precludes certain implementation strategies (e.g. because 
you can't detect changes to the list at that point, so you have to not 
cache any state that depends on the contents of the list).

The way _I_ would implement this if I were implementing in JS is via a 
getter that handed out a copy of the list, and probably mutation methods 
on my object to let people add/remove things from the list and maybe 
clear the list.  But I'm a bit paranoid about handing out objects by 
reference to people who may then do wacky things with them.  ;)

That then raises the question of whether handing out a copy should 
happen via method or property getter.  There seem to be strong feelings 
that handing out a copy via property getter is not OK.  I'm not sure how 
much I share those, but I can at least see the reasoning.

So my personal preference here would be a method to hand out an actual 
JS array by value, not by reference.  This does happen to mean that 
non-JS implementations don't have to do any JS anything until you ask 
for the array, and don't have to hold on to it once you do...  but I 
think that's what I would do in a pure-JS implementation too.

Now obviously you can disagree with several things in the above; I'm 
curious to know which specific ones you disagree with, if any.


Received on Monday, 5 November 2012 20:08:04 UTC