Re: crypto-ISSUE-37: Method naming [Web Cryptography API]

On Wed, Aug 29, 2012 at 6:08 PM, Wan-Teh Chang <wtc@google.com> wrote:

> On Tue, Aug 28, 2012 at 8:24 PM, Ryan Sleevi <sleevi@google.com> wrote:
> >
> > Solution 3:
> > Create objects for each of the "primitive" cryptographic operations,
> > and combine with Solution 2 to define constructors for each object.
> >
> > [Constructor(AlgorithmIdentifier algorithm, ...)]
> > interface Encrypter : CryptoOperation { ... };
> > interface Decrypter : CryptoOperation { ... };
> > interface KeyDeriver : KeyOperation { ... };
> > etc
> >
> > Sample Code:
> > var a = Encrypter(...);
>
> I like this solution the best.
>
> As for Encrypter vs. Encryptor, I think the misspelled HTTP "Referer"
> header shows programmers can live with it. We can avoid it with longer
> names like EncryptOperation or EncryptContext.
>
> Wan-Teh
>

One thing I'm not sure about Option 3 is whether or not JS applications
will be able to polyfill the particular algorithms if Encryptor is exposed
as a platform object, rather than the factory-function style.

Can an implementation do
function() {
  var real = Encryptor;
  Encryptor = function() {
    if (alg == "myFooAlg") {
      return new MyFooObject(... arguments ...);
    } else {
      return new real(... arguments ...);
    }
  }
}()

Or is window.crypto.Encryptor/the "Encryptor" object protected?

What I dislike about 3 is that it implies a class hierarchy, of which
JavaScript isn't really class-based (it's prototype). It also introduces a
number of objects into global scope.

Maybe

var e = window.crypto.Encryptor(...) ?