On 27 September 2010 12:51, Johan Brichau <johan@inceptive.be> wrote:
On 27 Sep 2010, at 11:28, Igor Stasenko wrote:
On 27 September 2010 11:54, Johan Brichau <johan@inceptive.be> wrote:
On 27 Sep 2010, at 10:38, Lukas Renggli wrote:
Am I wrong?
Yes, almost always one should probably use #= instead of #==.
I will add that to the exercise :-) The exercise actually makes students aware of the difference between strings and symbols (which should be pointer-equal)
I think you can avoid using 'equal' word when describing a #== comparison. It can be explained as 'test whether comparands are same object or not' while #= is test whether two objects equal or not.
Yes, this is exactly what the exercise is doing. I want them to be aware that equal _symbols_ are the same objects, but that equal _strings_ are not, which is why I let them evaluate:
a := #foobar. b := #foobar. a == b.
a := 'foobar'. b := 'foobar'. a == b
The problem is that evaluating the second snippet also yields true in Pharo/Squeak, so I cannot illustrate it using these snippets (which works fine in Visualworks, btw).
Yes, this is a compiler optimization and, yes, people should use #= instead of #== normally. But imho the optimization yields a wrong semantics, which is why I posted the email.
I have absolutely no clue if it can be changed (I am not familiar with the compiler implementation *at all*), but I would be happy to look over the shoulder of an experienced compiler hacker during the next sprint to learn ;-)
Why waiting for sprint? Implement String>>literalEqueal: anObject ^ self == anObject and then you have 'aaa' == 'aaa' -> false :)
cheers Johan _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.