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