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

[Chris Muller]

> > 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
>
> Can you point me to that discussion?

It's the thread I mentioned in the top of this thread (subject line:
"SHA512 squeak implementation").  Sorry I wasn't able to get you the
direct link (why do we care about this?) because the site at
http://lists.squeakfoundation.org/mailman/listinfo is down.  If you
have your own mail archive, the unique sentence string you can search
for within that thread is, "By bloat I didn't mean that the size of
the package is too large."

> > 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.
>
> Um, I don't remember ever saying I'm okay with anything like that. Can
> you give me a pointer where and when I did?

Well, I was just referring to things like I assume you've used String
streamContents: [ ...].  But, yes, it's an abstract class, so that's
different.

> The ByteString/WideString split was done before my time, but I'm sure the
> goal there was backwards compatibility. The comparison with SHA256 is not
> quite correct, because SHA256 is not an abstact class while String is.
>
> About "Numbers (LargePositive.., LargeNegative..., etc.)", you never send
> #new to any of those. You sometimes send #new: to LargePositiveInteger or
> LargeNegativeInteger, but  those are not abstract, and you want an
> instance of the class you sent #new: to. So, in that case #new: works as
> it should.

You're right.  It was just a question whether you thought the API
should guide or enforce the client into proper usage.  I got a little
zealous after seeing your plugin work.  The current factory we have is
fine.

 - Chris