Erik,
On 1 Jul 2017, at 09:41, Erik Stel <erik.stel@gmail.com> wrote:
Hi Francis,
You write:
Pharo Smalltalk Users mailing list wrote
FIY
UUID new asByteArray
does not give a ByteArray because UUID is a subclass of ByteArray and asByteArray returns self
(Entering teacher mode) This actually means that "UUID new asByteArray" does answer a ByteArray. It will answer (as you mentioned correctly) itself. Since a UUID is a ByteArray it means it will answer a ByteArray (in contrary to your statement).
To put it differently: The inheritance relation (UUID being a subclass of ByteArray) is a "IS-A" relation. So any UUID is a ByteArray.
This means however the message "asByteArray" did not have to be send of course (it is already a ByteArray). I was not sure the class UUID was actually a subclass of ByteArray when writing my reply. Turns out it is.
Not so fast. The discussion started with validating the final result which involved #=. Note that UUID new in: [ :uuid | uuid = (ByteArray readHexFrom: uuid hex) ]. => false UUID new in: [ :uuid | uuid hasEqualElements: (ByteArray readHexFrom: uuid hex) ]. => true SequenceableCollection>>#= fails when the classes/species involved are different, so even though UUID inherits from ByteArray, you cannot easily/naively compare them. Now, using #hasEqualElements: would solve the original problem (PBKDF2 derivedKeyHashFunction: SHA256 password: 'aSimplePassword' salt: '' iterations: 3000 length: 16 ) hasEqualElements: hashedPassword. Sven
Cheers, Erik
-- View this message in context: http://forum.world.st/Validate-password-with-PBKDF2-tp4952973p4953168.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.