[Pharo-project] Smalltalk (Pharo) and String equality
Hi, Something strange to me: '2' = '2'. -> true (OK) (2 asString) = (2 asString). -> true (OK) (2 asString) == (2 asString). -> false (OK) '2' == '2'. -> true ????? Laurent
this is because of an optimisation string inside the same methods are reused. if you want to show that string are different than symbol use two methods returning the same strings On Jan 17, 2010, at 6:30 PM, laurent laffont wrote:
Hi,
Something strange to me:
'2' = '2'. -> true (OK) (2 asString) = (2 asString). -> true (OK)
(2 asString) == (2 asString). -> false (OK) '2' == '2'. -> true ?????
Laurent _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I think the same happens in Java. It is a VM optimization. Compare "Something" == "Something" true On Sun, Jan 17, 2010 at 6:33 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
this is because of an optimisation
string inside the same methods are reused.
if you want to show that string are different than symbol use two methods returning the same strings
On Jan 17, 2010, at 6:30 PM, laurent laffont wrote:
Hi,
Something strange to me:
'2' = '2'. -> true (OK) (2 asString) = (2 asString). -> true (OK)
(2 asString) == (2 asString). -> false (OK) '2' == '2'. -> true ?????
Laurent _______________________________________________ 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
On Sun, Jan 17, 2010 at 6:33 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
this is because of an optimisation
string inside the same methods are reused.
OK
if you want to show that string are different than symbol use two methods returning the same strings
Hey !! Telepathy power ? You've used the force ? You master the Wakfu ? Laurent
On Jan 17, 2010, at 6:30 PM, laurent laffont wrote:
Hi,
Something strange to me:
'2' = '2'. -> true (OK) (2 asString) = (2 asString). -> true (OK)
(2 asString) == (2 asString). -> false (OK) '2' == '2'. -> true ?????
Laurent _______________________________________________ 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
On Jan 17, 2010, at 6:30 PM, laurent laffont wrote:
Hi,
Something strange to me:
'2' = '2'. -> true (OK) (2 asString) = (2 asString). -> true (OK)
(2 asString) == (2 asString). -> false (OK) '2' == '2'. -> true ?????
Yes, the same string in the same method points to the same entry in the literalframe. Which explains why this method works: strange 'hello world' isString ifTrue: ['hello world' become: {0}]. 'hello world' at: 1 put: ('hello world' at:1) + 1 . ^'hello world' at: 1. Put this method in Object, than print multiple times: Object new strange :-) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
One of my first bug in st80 was strange ^('foo' writeStream) nextPutAll: '-bar'; contents. At that time, writing pastEnd did use become: But if you really have time to pick an immutability bit in Newspeak, we don't have to care anymore. Nicolas 2010/1/17 Marcus Denker <marcus.denker@inria.fr>:
On Jan 17, 2010, at 6:30 PM, laurent laffont wrote:
Hi,
Something strange to me:
'2' = '2'. -> true  (OK) (2 asString) = (2 asString). -> true  (OK)
(2 asString) == (2 asString). -> false  (OK) '2' == '2'. -> true  ?????
Yes, the same string in the same method points to the same entry in the literalframe.
Which explains why this method works:
strange     'hello world' isString ifTrue: ['hello world' become: {0}].     'hello world' at: 1 put: ('hello world' at:1) + 1 .     ^'hello world'  at: 1.
Put this method in Object, than print multiple times:
    Object new strange
:-)
-- Marcus Denker  -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Jan 17, 2010, at 6:57 PM, Nicolas Cellier wrote:
But if you really have time to pick an immutability bit in Newspeak, we don't have to care anymore.
Hmm... the code below should even work with immutable strings. I *never* touch the string! I do not even manipulate the literal array via #at:put:... I just become the pointer to an Array generated with {}, which would not be immutable... So I wonder if the immutability solved the problem. (immutable literals do solve many other bugs when the object itself gets modified...).
strange 'hello world' isString ifTrue: ['hello world' become: {0}]. 'hello world' at: 1 put: ('hello world' at:1) + 1 . ^'hello world' at: 1.
Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
2010/1/17 Marcus Denker <marcus.denker@inria.fr>:
On Jan 17, 2010, at 6:57 PM, Nicolas Cellier wrote:
But if you really have time to pick an immutability bit in Newspeak, we don't have to care anymore.
Hmm... the code below should even work with immutable strings. I *never* touch the string! I do not even manipulate the literal array via #at:put:...
I just become the pointer to an Array generated with {}, which would not be immutable...
So I wonder if the immutability solved the problem. (immutable literals do solve many other bugs when the object itself gets modified...).
I extrapolated a bit... In VW, this leads to an immutability error: ('abc' become: #(1 2 3)) at: 1 Nicolas
strange     'hello world' isString ifTrue: ['hello world' become: {0}].     'hello world' at: 1 put: ('hello world' at:1) + 1 .     ^'hello world'  at: 1.
    Marcus
-- Marcus Denker  -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sun, 17 Jan 2010, Nicolas Cellier wrote:
One of my first bug in st80 was
strange ^('foo' writeStream) nextPutAll: '-bar'; contents.
At that time, writing pastEnd did use become:
But if you really have time to pick an immutability bit in Newspeak, we don't have to care anymore.
If I had a free bit in the object header, I'd use it for extending the identity hash instead of useless things like immutability. IMO it was a mistake to add immutability for literals in other smalltalks only to avoid possible errors generated by the broken stream/collection semantics. Levente
Nicolas
2010/1/17 Marcus Denker <marcus.denker@inria.fr>:
On Jan 17, 2010, at 6:30 PM, laurent laffont wrote:
Hi,
Something strange to me:
'2' = '2'. -> true  (OK) (2 asString) = (2 asString). -> true  (OK)
(2 asString) == (2 asString). -> false  (OK) '2' == '2'. -> true  ?????
Yes, the same string in the same method points to the same entry in the literalframe.
Which explains why this method works:
strange     'hello world' isString ifTrue: ['hello world' become: {0}].     'hello world' at: 1 put: ('hello world' at:1) + 1 .     ^'hello world'  at: 1.
Put this method in Object, than print multiple times:
    Object new strange
:-)
-- Marcus Denker  -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ 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
Levente Uzonyi wrote:
On Sun, 17 Jan 2010, Nicolas Cellier wrote:
One of my first bug in st80 was
strange ^('foo' writeStream) nextPutAll: '-bar'; contents.
At that time, writing pastEnd did use become:
But if you really have time to pick an immutability bit in Newspeak, we don't have to care anymore.
If I had a free bit in the object header, I'd use it for extending the identity hash instead of useless things like immutability. IMO it was a mistake to add immutability for literals in other smalltalks only to avoid possible errors generated by the broken stream/collection semantics.
Literal immutability and other object immutability is only one use of the so-called "immutability" bit. In reality, this bit is a "track modifications" bit, and I find the other uses much more valuable. Regards, -Martin
On Sun, 17 Jan 2010, Martin McClure wrote:
Levente Uzonyi wrote:
On Sun, 17 Jan 2010, Nicolas Cellier wrote:
One of my first bug in st80 was
strange ^('foo' writeStream) nextPutAll: '-bar'; contents.
At that time, writing pastEnd did use become:
But if you really have time to pick an immutability bit in Newspeak, we don't have to care anymore.
If I had a free bit in the object header, I'd use it for extending the identity hash instead of useless things like immutability. IMO it was a mistake to add immutability for literals in other smalltalks only to avoid possible errors generated by the broken stream/collection semantics.
Literal immutability and other object immutability is only one use of the so-called "immutability" bit. In reality, this bit is a "track
http://www.cincomsmalltalk.com/blog/blogView?entry=3232889180
modifications" bit, and I find the other uses much more valuable.
I wonder how that works. Levente
Regards,
-Martin
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/1/17 Levente Uzonyi <leves@elte.hu>:
On Sun, 17 Jan 2010, Martin McClure wrote:
Levente Uzonyi wrote:
On Sun, 17 Jan 2010, Nicolas Cellier wrote:
One of my first bug in st80 was
strange   ^('foo' writeStream) nextPutAll: '-bar'; contents.
At that time, writing pastEnd did use become:
But if you really have time to pick an immutability bit in Newspeak, we don't have to care anymore.
If I had a free bit in the object header, I'd use it for extending the identity hash instead of useless things like immutability. IMO it was a mistake to add immutability for literals in other smalltalks only to avoid possible errors generated by the broken stream/collection semantics.
Literal immutability and other object immutability is only one use of the so-called "immutability" bit. In reality, this bit is a "track
http://www.cincomsmalltalk.com/blog/blogView?entry=3232889180
Sure, object databases are more interesting applications, since you generally make such mistake only once. As a beginner, I put a halt in the method once identified as the source of the problem, and did not understand my mistake at first shot since it started working again (being recompiled). The good thing is that it helped me learning some Smalltalk superpowers faster :). Nicolas
modifications" bit, and I find the other uses much more valuable.
I wonder how that works.
Levente
Regards,
-Martin
_______________________________________________ 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
Nicolas Cellier wrote:
Sure, object databases are more interesting applications, since you generally make such mistake only once. As a beginner, I put a halt in the method once identified as the source of the problem, and did not understand my mistake at first shot since it started working again (being recompiled). The good thing is that it helped me learning some Smalltalk superpowers faster :).
Yes, I love the way that you can come to understand Smalltalk through debugging it. Modification tracking is good for more than just object databases. Object-relational mapping, distributed object systems, debugging, analysis, probably more -- all benefit from being able to tell when an object is modified, and all care at a different level of abstraction from the application itself, so it's better if you don't have to put the modification-detection code in the application code. Regards, -Martin
participants (7)
-
laurent laffont -
Levente Uzonyi -
Marcus Denker -
Mariano Martinez Peck -
Martin McClure -
Nicolas Cellier -
Stéphane Ducasse