Perhaps the discussion I wanted to raise is not about the use of '==' but about the fact that equal string literals in the same method body are optimized to be the same object.
Without immutability, such optimization is just plain wrong. In addition, it does not even seem to be a particularly useful optimization.

The use of '==' in the exercise is exactly about the reflective semantics, btw.

Johan

On 28 Sep 2010, at 10:05, Niko Schwarz wrote:

> But that's the point, there should be no business semantics to '=='.
> Only reflective semantics. The reflective semantics are ok.
>
> Niko
>
> On Mon, Sep 27, 2010 at 11:51 AM, 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 ;-)
>>
>> cheers
>> Johan
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> http://scg.unibe.ch/staff/Schwarz
> twitter.com/nes1983
> Tel: +41 076 235 8683
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project