On 08 May 2014, at 02:11, [email protected] wrote: > "Mariano Martinez Peck"<[email protected]> wrote: >> I had the same problem. I added the following to my compatibility package. >> In Pharo now I do: >> >> shaHashMessage: aString >> "this method hashes aString using a SHA1 (SecureHashAlgorithm) method. >> Returns an integer" >> ^ (SHA1 new hashStream: aString readStream) asInteger > > This is very ambiguous API. SHA1 (and in fact all secure hash functions) are > defined in terms of bytes, (bytes in, bytes out). This method doesn't specify > the transformation that turns the aString into bytes (presumably some kind of > encoding, but what is it?) and what transformation it does to turn the 20 > bytes of SHA1 result into an Integer (does it interpret the bytes as big > endian/little endian, or maybe it throws every second byte away in the > process). It's OK to wrap the basic hashing API in helpers that accept other > types of arguments for common use cases, but the basic API definitely should > be bytes in/bytes out.
Yes, very true. Like Esteban said, that is why we changed it. > HTH, > > Martin > >
