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
