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

On 7/14/14, 4:42 PM, Ryan Sleevi wrote:
> 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"

Mmmm, magic.  ;)

>        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

No, WebIDL doesn't mess with properties it didn't define.

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

Precisely.  People do this all the time with IDL objects (especially 
Window and nodes of various sorts, but also nodelists and the like); 
it's called "expandos".

> "Whatever makes everyone happy" ;)

I want a unicorn too!  ;)

Seriously, I think we'll get somewhere here.  I really do.

Just to make sure we're on the same page, by the way, do the 
dictionaries coming from CryptoKey.algorithm ever have missing 
properties, or are they always completely filled in?

>     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

Well, IDL could define it generically.  But you could define how to 
clone your particular dictionaries specifically.

> 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.

Exactly.

-Boris

Received on Monday, 14 July 2014 22:45:59 UTC