More over, the optimisation seems quite short sighted : | x | x := #( 'a' 'a'). ^x first == x last
-> false For example, if I encode some "data" in an Array with strings, I can expect more frequent repetitions (I know, not very object oriented/ could also use Symbol/etc... but think of a simple 2D game), Nicolas 2010/9/28 Eliot Miranda <[email protected]>: > > > On Tue, Sep 28, 2010 at 7:39 AM, Johan Brichau <[email protected]> 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. > > I think it's orthogonal to immutability. Non-immutable literals are "just > plain wrong" (actually unsafe). The optimization is confusing and > unexpected to the inexperienced. But I emphatically agree with the last > part; it's not a particularly useful optimization. > cheers > Eliot >> >> 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 > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
