[Bug 26322] Definitions "algorithm" and "usages" properties of CryptoKey make no sense

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26322

--- Comment #13 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Boris Zbarsky from comment #12)
> > For [[usages]] we will explicitly state the values of the members of the Array.
> 
> Or create it from an IDL sequence.  That would make sure that the array is
> created in the right way (the one that's side-effect-free).  Just stating
> the values of the Array members doesn't define how those members get defined
> on the Array, which is important here.
> 
> > The algorithm and usages attributes, rather than 'reflecting' the contents of
> > the ... internal slot will simply 'return' the contents of that slot.
> 
> Yep.
> 
> And changing usages (if that's possible) will throw the array in [[usages]]
> away and create a new one?
> 
> > Does this work ?
> 
> I think so, yes.

I don't think it does, or at least, I'd like to understand if I'm
misunderstanding something.

Putting a non-IDL primitive into the internal slot is something I was trying to
avoid, precisely because any non-IDL (e.g. ES object) can be mutated externally
(e.g. via the prototype chain), as well as all accesses externally visible
(i.e. when I get an item at index 2, that can be noticed through the prototype)

Object.freeze solves the mutation issue, but it doesn't solve the fact that I'm
going through the prototype.

I thought the proposed solution here was to:
1) Set an internal slot for the IDL/internal representation of an object, so
that it can be accessed and/or mutated without any externally-visible (to ES)
effects
2) Set an ADDITIONAL internal slot for the "public" representation, which would
be the "cached" object

I also don't understand how "cached" object is compatible with object freezing.
I definitely got the feedback that "freezing is the anti-pattern", especially
for this set of problems. A cached object - where script mutations (if any) are
externally visible but not internally visible - seemed consistent with the
existing DOM objects.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Wednesday, 8 October 2014 21:25:09 UTC