Nicolas Petton wrote:
> On Apr 24, 2012, at 11:49 PM, Herby Vojčík wrote:
>
>> Hi,
>>
>> I have the question(s) on implementation of equality:
>>
>> - why is there identityhash comparision in `Object>> #==`, what is wrong with Javascript === ?
>
> JavaScript === is for equality (like == but without type-casting). Object>> == is for identity.
Well, maybe it's Smalltalk legacy, but I always saw JS === as identity;
at least for typeof "object" it behaves such, as per ECMA-262 5.1 11.9.6:
...cover non-object cases...
7. Return true if x and y refer to the same object. Otherwise, return false.
>> - why is Javascript == used in various #= implementations? == is tricky, it does unnecessary type-castings. It is recommended to use === whenever possible.
>
> True, but JS *is* tricky :)
> Fo Smalltalk classes representing JS literals, like String and Number, there's some implicit type conversion with some message sends. instances of String are still strings, but augmented, so === doesn't work.
>
> |a|
> a := 'hello' yourself.
> <a === 'hello'> -> false
> <a == 'hello'> -> true
>
> |a|
> a := 'hello'.
> <a === a._yourself()> -> false
Aw! That is bad, I would bet this is true...
That's why there is proliferation of <return String(self) ===
String(aString)> codes there, isn't it?
I thought you monkey-patched actual String(Number, etc.).prototype, so
that you can treat actual JS strings, number etc. as native Amber
objects... probably not.
>> - (optimization question) shouldn't there be `<if (self === anObject) return true;>` at the beginning of `Object>> #==`, at least, as a quick shortcut; or is lazy generation of identityHash a wanted thing?
> No, because it's equality.
At least for typeof object it would probably work, but question is if it
is good enough then... I very hope there are no two objects (JS typeof
"object") that share same identityHash.
> Cheers,
> Nico
Thanks, Herby
Locked
