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
cryptography@lists.squeakfoundation.org