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