Re: Spec for CryptoKey.algorithm and CryptoKey.usages doesn't really make sense

On Mon, Jul 14, 2014 at 1:20 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

>
>>  So having [[algorithm_copy]] (or whatever) seems to violate that, in
>> that it leads to different behaviour that KeyAlgorithm-as-an-interface.
>>
>
> Well, sure.  I mean the TAG was asking for different behavior, right?


Not really "different behaviour", so much as "Just use dictionary and magic
it away with prose if that's the only reason you're creating interfaces"


>  Perhaps I've been confused by your explanation. If we were to think of
>> KeyAlgorithm as an interface (rather than a Dictionary), it would seem
>> to align with Option C, in as much as the object is 'frozen' by virtue
>> of no setters / setters that throw TypeError, recursively?
>>
>
> Being frozen is actually a much stronger constraint than what WebIDL
> provides by default, hence my mention of variants of (C) to avoid the full
> effects of freezing.  For example, if .algorithm is a frozen object then
> doing this:
>
>   someCryptoKey.algorithm.lettuce = "present";
>
> will be a no-op in non-strict mode and throw in strict mode.


Is that really stricter? That's exactly what I expect Web IDL to do if
KeyAlgorithm was an interface, for the same reason that
someCryptoKey.algorithm = "bar" is the no-op-or-throw

So if .algorithm returns an Interface (which CryptoKey is as well), then
someCryptoKey.algorithm.name = "foo" will also no-op-or-throw.

Or are you saying that, in an Interface world, someCryptoKey.algorithm.name
is a no-op-or-throw, but someCryptoKey.algorithm.lettuce = "present" or
someCryptoKey.tomato = "present" are valid?


> I can provide specific language once I know what our exact behavior goals
> are.  The problem is that I can't decide on those behavior goals, because
> I'm not sure what constraints we're operating under in terms of the API
> behavior.


"Whatever makes everyone happy" ;)


> Well, you just have to define what it does.  For example structured
> cloning of an IDL dictionary that contains only string members might create
> another instance of the same kind of IDL dictionary that copies over the
> values of the members that are present in the one being structured cloned.
>  It's a bit cumbersome to write down, I agree.
>


> Further, since I can't "directly" copy [[foo]], I presumably invoke the
>
>> Web IDL conversion from [[foo_copy]] to recreate [[foo]] on the new
>> object.
>>
>
> No, you hand-define the direct copy of [[foo]] as needed.  Perhaps that
> part should move into Web IDL itself in the long term...


This sounds like it's a new (blocking) request for Web IDL then, which is
to define a way to "clone" IDL types (assuming terminology is correct), but
does seem it would 'solve' the issue, by declaring that newObject.[[foo]]
is a 'clone' of oldObject.[[foo]], where [[foo]] contains an IDL type (such
as an Algorithm dictionary), and [[foo_exposed]] is the result of
converting that to an ES dictionary.

Received on Monday, 14 July 2014 20:42:35 UTC