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

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

--- Comment #16 from Mark Watson <watsonm@netflix.com> ---
(In reply to Ryan Sleevi from comment #15)
> (In reply to Boris Zbarsky from comment #14)
> > > 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
> > 
> > Yes.  I assumed that's what Mark was talking about.  Did I misunderstand?
> 
> My understanding was that the proposed solution was to set [[usages]] (e.g.
> what affects internal consumption), rather than introduce a
> [[usages_exposed]] that reflects the attribute value in a cached manner, but
> is not used for any access checks.
> 

Yes, that was what I proposed. But it only works if that freezing that object
really means it cannot be mutated by the script and if internal access to the
properties / array elements doesn't have any script-visible side-effects.

> I don't understand why we'd Object.freeze if doing a [[usages_exposed]] -
> don't the existing [Cached] IDL objects already reflect any ES modifications
> to them (directly or via prototype chain)? That is, they always return the
> same ES object - which may have been mutated.

If that's what developers expect, I guess we should do that. However to me it
seems very odd that I can modify the algorithm attribute of a CryptoKey - odd
that I can modify it at all and more odd that once I do these changes have no
effect on the CryptoKey's behavior.

Equally for usages: isn't it at least confusing that I can modify the usages
Array of a CryptoKey but this does not affect what it can be used for ?

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

Received on Wednesday, 8 October 2014 23:02:57 UTC