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
> 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.