On Sep 28, 2010, at 4:39 PM, Johan Brichau wrote:

> 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.

Yes this is true. :)
We will fix it with Opal.

Stef

> 
> 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 <[email protected]> wrote:
>>> 
>>> On 27 Sep 2010, at 11:28, Igor Stasenko wrote:
>>> 
>>>> On 27 September 2010 11:54, Johan Brichau <[email protected]> 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
>>> [email protected]
>>> 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
>> [email protected]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> 
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to