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

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

--- Comment #2 from Boris Zbarsky <bzbarsky@mit.edu> ---
If you haven't read https://www.w3.org/Bugs/Public/show_bug.cgi?id=23682#c0 and
https://github.com/whatwg/notifications/issues/18#issuecomment-50470249 you
probably should.

It sounds like you want a readonly attribute returning an object.  Since it's
an attribute, you want to return the same object each time.  You want mutations
to that object to not affect your internal state (or possible to just be
impossible).

The reason you need the "internal slot" stuff is because the requirement that
the same object be returned each time requires you to internally cache this
object-to-be-returned somewhere.  That's all an "internal slot" is: some place
to put some data.  In this case, your CryptoKey will have two internal slots
related to "usages", for example: one for storing the actual usages and one for
storing the cached object it created.

If you want to prevent mutations, you can also freeze the JS Array you return,
though some people consider this an API antipattern.  Even without this,
mutations won't affect your internal state, obviously, but will affect what
page JS consumers see if one of them decides to mutate the array.

If/when we add something like [Cached] to Web IDL, the part about storing the
cached value will be handled by the IDL itself.  This is what Gecko has right
now, for example.  The IDL for "usages" in Gecko is:

  [Cached, Constant, Frozen] readonly attribute sequence<KeyUsage> usages;

Here [Constant] is something akin to the spec's [SameObject], [Cached] is the
thing that causes the binding layer to automatically cache the value on get,
and [Frozen] means to freeze the array after converting the sequence to a JS
value....

That doesn't help you right this second, sadly, since Web IDL doesn't have
[Cached] yet, though depending on schedules you could try using it and hoping
it grows it by the time you need to be advancing in the process...

> I don't think we much care

_I_ care.  They shouldn't be called!

> and ideally consistent across different platform objects following similar
> patterns

You want consistency with ES built-ins that create arrays, with array literals,
and with methods that return sequence values.  That means not calling anything
page-observable during creation of the array.

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

Received on Friday, 26 September 2014 16:13:54 UTC