[Cryptography Team] [Vm-dev] Smalltalk code calling SHA2Plugin

[Chris Muller]

Hi,

The most recent VMs ship with the plugins.
>

I didn't know, that's good news!


> > > I decided against the practice of making #new return an instance of
> > > another class than the receiver, as it was with the previous
> > > implementation, because that makes it a lot harder for others to
> > > understand the code.
> >
> > Hm.  I sort of agree, although I guess Factory is a recognized pattern.
> To me, the issue is that writing
> >
> >       "SHA256 new"
> >
> > , is a perfectly intuitive and obvious way to use it, but sticking out
> like a sore thumb as a subversively-wrong-way to-use-it.  It'd be better if
> it threw an error, and even better than that if it just worked.

>
> > I know you care about the quantity of methods in the image (as do I),
> how about quality?  Can SHA256 #new be improved by doing essentially what
> HashFunction #newSHA256 does, and simply sending some alternative to new
> (i.e.,
>
> It's not clear what do you mean by caring about the quantity of methods.
>

What you referred to as "bloat" in the discussion about loading all crypto
primitives or not.  After Robert had mentioned the size in K bytes, you'd
mentioned you cared about the number of methods in classes, not so much
their size in bytes.  To which I agree, although I think you take it a lot
further than me (i.e., Time microsecondClockValue).

> basicNew initialize) to avoid the recursion?
>
> That would do exactly what I do not want to do: #new would return an
> object whose class is not SHA256.
>

Okay, now I understand.  This gets back to one of our core differences in
philosophy -- your greater concern over *types* vs. mine over *API's*.
You're okay with it for Strings (ByteString vs. WideString) and Numbers
(LargePositive.., LargeNegative..., etc.), and probably a few others.  But
not SHA256.  IMO, letting different implementations with the same API be
interchangeable is what leverages Smalltalk's late-binding power.

 - Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/cryptography/attachments/20200721/fba7ddf6/attachment.html>