Good point, Chris. However if we copy SHA256 to SHA256InImage, then #new sent to a concrete subclass would work in your use case, and we would have SHA256 new as the factory method. Each concrete subclass would code #new as ^ self basicNew initialize; yourself. Or we could define a #newConcrete method and refer to that in subclass #new. Heck I believe that SHA256>>#new could check the receiver class and do the appropriate instantiation.
K, r
On 7/22/20 2:16 PM, Chris Muller wrote:
Yes, that is one use-case, but another is when you want an actual SHA256, regardless whether the plugins are loaded, or not. For its test cases, for example. So, were #new to become the factory method, it would spoil the API for THAT use-case.
On Wed, Jul 22, 2020 at 12:47 PM Robert Withers robert.withers@pm.me wrote:
Hi Levente,
I must admit, after reflection, that I LIKE that SHA256 new may return a different class. Essentially, the #new method of SHA256, in this scenario, will be the factory method, instad of HshFunction newSHA256. This factory method may return a pluginized SHA256 concrete subclass or itself as default. The reason I like this is that we would reference the "abstract" class specific to the hash algorithm as SHA256, exactly the same lexeme.
In our current case, the SHA256 is also a concrete class, the default when no plugins around. If this duality of SHA256 being both abstract and concrete, is an issue, we could copy SHA256 to SHA256InImage and then have a proper strict abstract class. This is my feeling that opposite of creating confusion it specifies the Lexeme of this hashFunction and so clarifies.
Newbie: "How do I use SHA256?"
Wise Council: "Code it as SHA256 new. Then send hashStream: to it.".
Jester: "Watch out it is tricky picky. It may return an instance of a DIFFERENT concrete class....correctly so.
my 2 pennies,
Kindly, rabbit
On 7/21/20 9:56 PM, Levente Uzonyi wrote:
Hi Robert,
On Tue, 21 Jul 2020, Robert wrote:
Hub Levente,
I like the idea of SHA256 and friends to throw an exception when #new is called directly SHA256 new. With a message to call newSHA256.
What do you think?
I think #new should return an instance of the receiver. That's what everyone expects when #new is sent to a class, isn't it? And if #new raised an error, what would #newSHA256 send to create an instance? #basicNew + #initialize? I don't like that.
Levente
Kindly, Robert
On Tue, Jul 21, 2020 at 14:02, Levente Uzonyi [leves@caesar.elte.hu](mailto:leves@caesar.elte.hu) wrote: Hi Chris,
On Mon, 20 Jul 2020, Chris Muller wrote: > Hi Levente, > > > > HashFunction newSHA256 > > > > > > instead of > > > > > > SHA256 new > > > > > > in order to take advantage of Levente's plugin. > > > > That is indeed some sort of a change but it only affects those who > > compiled the SHA256Plugin themselves since that plugin wasn't shipped with > > the VM. > > Ah, you're speaking about legacy code. I really hope we can include your plugin in future VM's. Are Eliot, et al, on board? The most recent VMs ship with the plugins. > > 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. > 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. > > Above, you mentioned you decided against the practice, does that mean you're writing: > > SHA256 newSHA256 > > ? If not, how did you do it? Use HashFunction's class side #new* methods to create the instances. HashFunction is a facade and a factory at the same time. I originally wanted to create a separate class for this role named Hasher, but HashFunction seemed to work just as well. Levente > > Thanks again for this great work. > > - Chris > > > On Sun, Jul 19, 2020 at 9:55 PM Levente Uzonyi[leves@caesar.elte.hu](mailto:leves@caesar.elte.hu) wrote: > Hi Chris, > > On Sun, 19 Jul 2020, Chris Muller wrote: > > > Hi Robert and Levente, > > > > Yes, I *think* so! I'm just now getting up to speed after reading > > that epic thread between you and Levente (subject line: "SHA512 squeak > > implementation"). Thanks a ton to both of you, BTW, for this work! > > > > After loading > > > > ProCrypto-1-1-1 > > and ProCryptoTests-1-1-1, > > > > all 205 tests are passing, however, it took me a bit to realize I need to use > > > > HashFunction newSHA256 > > > > instead of > > > > SHA256 new > > > > in order to take advantage of Levente's plugin. This is great, thanks again! > > That is indeed some sort of a change but it only affects those who > compiled the SHA256Plugin themselves since that plugin wasn't shipped with > the VM. > 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. > > > > > Quick side question: Is it okay to reuse a SHA256 instance, or should > > I just create a new one for each and every message to hash? > > All subinstances of HashFunction are reusable. The tests > (see HashFunctionTest) do exactly that. > > > Levente > > > > > Best, > > Chris > > > > > > On Sat, Jul 18, 2020 at 6:02 AM Robert Withers [robert.withers@pm.me](mailto:robert.withers@pm.me) wrote: > >> > >> Hey Chris, > >> > >> Did this approach fix your issues? > >> > >> Kindly, > >> rabbit > >> > >> On 7/13/20 11:46 PM, Robert wrote: > >> > >> Hi Chris, > >> > >> You should only need to run #3, which will load Registers. Hasher was from before we integrated the code into ProCrypto-1-1-1. > >> > >> Installer as project: ‘Cryptography’; install: ‘ProCrypto-1-1-1’. > >> > >> Then to load tests run: > >> > >> Installer as project: ‘Cryptography’; install: ‘ProCryptoTests-1-1-1’. > >> > >> Let us know if any tests fail and we can look into it. > >> > >> Kindly, > >> Robert > >> > >> > >> On Mon, Jul 13, 2020 at 19:52, Chris Muller [asqueaker@gmail.com](mailto:asqueaker@gmail.com) wrote: > >> > >> Hi Robert, hi Levente, > >> > >> I would like to utilize the latest crypto in my next project, would > >> you help me with the current proper way to configure my image, and my > >> vm with plugins? > >> > >> (image) > >> In going back through some recent messages on the mailing lists and > >> instructions on squeaksource.com , I came across these incantations as > >> current ways to load the image code: > >> > >> 1) Installer ss > >> project: 'Registers'; > >> install: 'Registers'; > >> project: 'Hasher'; > >> install: 'HAHasher-Core'; > >> install: 'HAHasher-Tests'. > >> > >> 2) Installer ss > >> project: 'Registers'; > >> install: 'Registers'; > >> project: 'Hasher'; > >> install: 'HAHasher'. > >> > >> 3) Installer ss project: 'Cryptography'; install: 'ProCrypto-1-1-1'. > >> > >> I like these one-click-for-everything scripts for crypto -- it > >> satisfies the good use-case of development and education, and also > >> knowing all what's available to Squeak in one glance. My app's build > >> script can cherry pick what it needs, but any advice on which starting > >> point above or otherwise is appreciated. > >> > >> (vm) > >> I put the SHA2Plugin.so from Roberts dropbox in the lib directory, > >> and it shows up as a "Loaded VM Module" in About Squeak. But, three > >> of the "WithPluginTest"'s are failing. My OS is linux_x64. I don't > >> know how to build Squeak or plugins from sources, but including it in > >> the standard precompiled vm would be so pertinent for Squeak today, > >> IMO. SHA256 is one of the ones I'm going to need, so would be nice to > >> have it work via plugin. I assume it's a lot faster? > >> > >> Thanks, > >> Chris > >> > >> On Tue, Mar 10, 2020 at 3:52 PM Levente Uzonyi [leves@caesar.elte.hu](mailto:leves@caesar.elte.hu) wrote: > >>> > >>> > >>> Hi Robert, > >>> > >>> With yesterday's help from Eliot and Nicolas, the SHA2Plugin is ready: > >>> http://squeaksource.com/Cryptography/CryptographyPlugins-ul.19.mcz
>> The updated version of the image-side code is available in the Hasher
> >>> repository. You can install it with: > >>> > >>> Installer ss > >>> project: 'Registers'; > >>> install: 'Registers'; > >>> project: 'Hasher'; > >>> install: 'HAHasher-Core'; > >>> install: 'HAHasher-Tests'. > >>> > >>> > >>> Levente > >>> > >>> > >>> On Tue, 10 Mar 2020, Levente Uzonyi wrote: > >>> > >>>> > >>>> Hi Robert, > >>>> > >>>> Please have a look at: > >>>>http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-March/207851.htm...
>>> It answers all your questions.
> >>>> > >>>> > >>>> Levente > >>>> > >>>> On Tue, 10 Mar 2020, Robert wrote: > >>>> > >>>>> Hi Levente, > >>>>> > >>>>> I got the SHA2Plugin built and deployed to my Crypto plugins folder. Now I > >>>> am trying to figure out how to call it from SHA512. > >>>>> > >>>>>https://www.dropbox.com/sh/yhv253rwrhq0q5p/AAB7PKP2KPiGpDnIyule2h_Ia?dl=0
>>>>
> >>>>> [plugin] I looked at it and please understand I think the classes you wrote > >>>> and the framework is really quite nice. I am thrilled we found SHA512! It's > >>>> impressive that your one plugin can handle a number of hash functions! > >>>>> Now all I need is to find the code that calls the SHA2Plugin. Levente, > >>>> would you share that code, please? > >>>>> > >>>>> Kindly, > >>>>> Robert > >>>>> > >>>>> > >>>> > >> > >> > >> > > > > >