"Works fine" is a value judgment that can cut both ways: one could also argue that VW lacks a useful optimization of literals. Non-literal strings should do what you want.
Bill ________________________________________ From: [email protected] [[email protected]] On Behalf Of Levente Uzonyi [[email protected]] Sent: Monday, September 27, 2010 8:03 AM To: [email protected] Subject: Re: [Pharo-project] ('a' == 'a') == true ? On Mon, 27 Sep 2010, Johan Brichau 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). If you evaluate it line by line, it will work as you expected. So you can even show how the compiler optimization works by evaluating it both ways. Levente > > 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 > _______________________________________________ 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
