W3C home > Mailing lists > Public > public-webcrypto@w3.org > April 2014

[Bug 25388] Boolean arguments

From: <bugzilla@jessica.w3.org>
Date: Tue, 29 Apr 2014 21:00:37 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-25388-7213-WGT1aJy9uW@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25388

--- Comment #4 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Anne from comment #3)
> I would not suggest to nest objects, that does indeed seem bad. Can it be a
> keyUsages parameter with values as per Mark's suggestion?
> 
> The main problem is that if you look at a call such as
> 
> window.crypto.subtle.deriveKey({ alg }, key, { derived alg }, false, [
> "encrypt" ]);
> 
> it is not clear what is going on. The same with the last argument being a
> length of sorts. 

A length? Not sure I follow.

> 
> I would need a much better understanding of the problem space to give more
> informed feedback as to what a better API would be. :-(

I didn't take Mark's comment as suggesting it was a KeyUsage, but in fact a new
enumeration. That is

window.crypto.subtle.deriveKey({ alg }, key, {derived alg}, "extractable", [
"encrypt " ]);

I took your reply as understanding it as

window.crypto.subtle.deriveKey({alg}, key, {derived alg}, ["extractable",
"encrypt"]);

The issue here is that "extractable", as a key usage, doesn't have a 1:1
mapping to a given operation - that is "extractability" ties to both exportKey
and wrapKey. Calling it "exportKey" doesn't conceptually fit, since you can
extract a key via wrapping. Calling it "wrapKey" is off the table, since
"wrapKey" is already a usage (indicating the given key can be used to wrap key,
not that it is itself wrappable)

As a style design, I can certainly understand why boolean positional arguments
are bad when used in abundance - eg: foo(true, false, true); However, it seems
a bit dogmatic to suggest that any boolean arguments are bad.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Tuesday, 29 April 2014 21:00:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:22 UTC