strange == behavior
Locked
 
|
Hi guys,
Playing with some recursive data-structure I have found some strange piece of behavior in Pharo. If in an workspace we try to evaluate: a := Association new.
a key: 3. a value: a. a == a value. the first time we get "true", the second we get an infinite loop...
A simple workaround is to declare "a": |a| a := Association new.
a key: 3. a value: a. a == a value. My question now is: Is this a bug or a feature ? By the way the same thing happens in 1.4 and 2.0 equally.
By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "."
Cheers, -- Dr. Ciprian TEODOROV Ingénieur Développement CAO tél : 06 08 54 73 48 mail : [hidden email] www.teodorov.ro |
|
|
by the way, we have the same thing in 1.0, 1.1, 1.3.
On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <[hidden email]> wrote: Hi guys, Dr. Ciprian TEODOROV Ingénieur Développement CAO tél : 06 08 54 73 48 mail : [hidden email] www.teodorov.ro |
|
|
Same behavior in Squeak 4.2 btw
----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
|
|
|
It seems that this issue can be fixed by modifying the = method in Association.
Association>>= anAssociation ^ super = anAssociation
and: [ value == anAssociation value ifTrue: [ true ]
ifFalse: [ value = anAssociation value ] ] Cheers... On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <[hidden email]> wrote:
Dr. Ciprian TEODOROV Ingénieur Développement CAO tél : 06 08 54 73 48 mail : [hidden email] www.teodorov.ro |
|
|
Can you add a issue at
? On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov <[hidden email]> wrote: It seems that this issue can be fixed by modifying the = method in Association. |
|
|
I reported. I am doing the slice.
2012/12/9 Marcus Denker <[hidden email]>
|
|
|
In reply to this post by Ciprian Teodorov-3
Hi guys
what is the impact on method =? Any ideas? Stef On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote: > It seems that this issue can be fixed by modifying the = method in Association. > > Association>>= anAssociation > ^ super = anAssociation > and: [ > value == anAssociation value > ifTrue: [ true ] > ifFalse: [ value = anAssociation value ] ] > > Cheers... > > On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <[hidden email]> wrote: > Same behavior in Squeak 4.2 btw > > ----------------- > Benoit St-Jean > Yahoo! Messenger: bstjean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > From: Ciprian Teodorov <[hidden email]> > To: [hidden email] > Sent: Saturday, December 8, 2012 11:11:44 AM > Subject: Re: [Pharo-project] strange == behavior > > by the way, we have the same thing in 1.0, 1.1, 1.3. > > On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <[hidden email]> wrote: > Hi guys, > > Playing with some recursive data-structure I have found some strange piece of behavior in Pharo. > > If in an workspace we try to evaluate: > > a := Association new. > a key: 3. > a value: a. > a == a value. > > the first time we get "true", the second we get an infinite loop... > > A simple workaround is to declare "a": > > |a| > a := Association new. > a key: 3. > a value: a. > a == a value. > > My question now is: Is this a bug or a feature ? > By the way the same thing happens in 1.4 and 2.0 equally. > > By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "." > > Cheers, > -- > Dr. Ciprian TEODOROV > Ingénieur Développement CAO > > tél : 06 08 54 73 48 > mail : [hidden email] > www.teodorov.ro > > > > -- > Dr. Ciprian TEODOROV > Ingénieur Développement CAO > > tél : 06 08 54 73 48 > mail : [hidden email] > www.teodorov.ro > > > > > > -- > Dr. Ciprian TEODOROV > Ingénieur Développement CAO > > tél : 06 08 54 73 48 > mail : [hidden email] > www.teodorov.ro |
|
|
The sole impact I can't think of is (#x -> Float nan) = (#x -> Float nan)
Nicolas 2012/12/9 Stéphane Ducasse <[hidden email]>: > Hi guys > > what is the impact on method =? > Any ideas? > > Stef > On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote: > >> It seems that this issue can be fixed by modifying the = method in Association. >> >> Association>>= anAssociation >> ^ super = anAssociation >> and: [ >> value == anAssociation value >> ifTrue: [ true ] >> ifFalse: [ value = anAssociation value ] ] >> >> Cheers... >> >> On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <[hidden email]> wrote: >> Same behavior in Squeak 4.2 btw >> >> ----------------- >> Benoit St-Jean >> Yahoo! Messenger: bstjean >> A standpoint is an intellectual horizon of radius zero. >> (Albert Einstein) >> From: Ciprian Teodorov <[hidden email]> >> To: [hidden email] >> Sent: Saturday, December 8, 2012 11:11:44 AM >> Subject: Re: [Pharo-project] strange == behavior >> >> by the way, we have the same thing in 1.0, 1.1, 1.3. >> >> On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <[hidden email]> wrote: >> Hi guys, >> >> Playing with some recursive data-structure I have found some strange piece of behavior in Pharo. >> >> If in an workspace we try to evaluate: >> >> a := Association new. >> a key: 3. >> a value: a. >> a == a value. >> >> the first time we get "true", the second we get an infinite loop... >> >> A simple workaround is to declare "a": >> >> |a| >> a := Association new. >> a key: 3. >> a value: a. >> a == a value. >> >> My question now is: Is this a bug or a feature ? >> By the way the same thing happens in 1.4 and 2.0 equally. >> >> By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "." >> >> Cheers, >> -- >> Dr. Ciprian TEODOROV >> Ingénieur Développement CAO >> >> tél : 06 08 54 73 48 >> mail : [hidden email] >> www.teodorov.ro >> >> >> >> -- >> Dr. Ciprian TEODOROV >> Ingénieur Développement CAO >> >> tél : 06 08 54 73 48 >> mail : [hidden email] >> www.teodorov.ro >> >> >> >> >> >> -- >> Dr. Ciprian TEODOROV >> Ingénieur Développement CAO >> >> tél : 06 08 54 73 48 >> mail : [hidden email] >> www.teodorov.ro > > |
Re: strange == behavior
|
|
In reply to this post by Stéphane Ducasse
I am not pro, see my comments in the issue tracker.
For example, | a | a := Association key: #foo. (a value: (Array with: a)) = (a value: (Array with: a)). would still loop. Loops like that cannot be prevented locally. See my other mail about prevent stack overflow. On 09 Dec 2012, at 16:32, Stéphane Ducasse <[hidden email]> wrote: > Hi guys > > what is the impact on method =? > Any ideas? > > Stef > On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote: > >> It seems that this issue can be fixed by modifying the = method in Association. >> >> Association>>= anAssociation >> ^ super = anAssociation >> and: [ >> value == anAssociation value >> ifTrue: [ true ] >> ifFalse: [ value = anAssociation value ] ] >> >> Cheers... >> >> On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <[hidden email]> wrote: >> Same behavior in Squeak 4.2 btw >> >> ----------------- >> Benoit St-Jean >> Yahoo! Messenger: bstjean >> A standpoint is an intellectual horizon of radius zero. >> (Albert Einstein) >> From: Ciprian Teodorov <[hidden email]> >> To: [hidden email] >> Sent: Saturday, December 8, 2012 11:11:44 AM >> Subject: Re: [Pharo-project] strange == behavior >> >> by the way, we have the same thing in 1.0, 1.1, 1.3. >> >> On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <[hidden email]> wrote: >> Hi guys, >> >> Playing with some recursive data-structure I have found some strange piece of behavior in Pharo. >> >> If in an workspace we try to evaluate: >> >> a := Association new. >> a key: 3. >> a value: a. >> a == a value. >> >> the first time we get "true", the second we get an infinite loop... >> >> A simple workaround is to declare "a": >> >> |a| >> a := Association new. >> a key: 3. >> a value: a. >> a == a value. >> >> My question now is: Is this a bug or a feature ? >> By the way the same thing happens in 1.4 and 2.0 equally. >> >> By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "." >> >> Cheers, >> -- >> Dr. Ciprian TEODOROV >> Ingénieur Développement CAO >> >> tél : 06 08 54 73 48 >> mail : [hidden email] >> www.teodorov.ro >> >> >> >> -- >> Dr. Ciprian TEODOROV >> Ingénieur Développement CAO >> >> tél : 06 08 54 73 48 >> mail : [hidden email] >> www.teodorov.ro >> >> >> >> >> >> -- >> Dr. Ciprian TEODOROV >> Ingénieur Développement CAO >> >> tél : 06 08 54 73 48 >> mail : [hidden email] >> www.teodorov.ro > > |
|
|
some years ago, its been a long discussion on squeak mailing list about that..
imo association should compare keys. not values. But self-referencing data structures is and will be a problem. And there is no easy solution: a := Array new: 1. a at:1 put: a. a = a On 9 December 2012 17:20, Sven Van Caekenberghe <[hidden email]> wrote: > I am not pro, see my comments in the issue tracker. > > For example, > > | a | > a := Association key: #foo. > (a value: (Array with: a)) = (a value: (Array with: a)). > > would still loop. > > Loops like that cannot be prevented locally. > > See my other mail about prevent stack overflow. > > On 09 Dec 2012, at 16:32, Stéphane Ducasse <[hidden email]> wrote: > >> Hi guys >> >> what is the impact on method =? >> Any ideas? >> >> Stef >> On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote: >> >>> It seems that this issue can be fixed by modifying the = method in Association. >>> >>> Association>>= anAssociation >>> ^ super = anAssociation >>> and: [ >>> value == anAssociation value >>> ifTrue: [ true ] >>> ifFalse: [ value = anAssociation value ] ] >>> >>> Cheers... >>> >>> On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <[hidden email]> wrote: >>> Same behavior in Squeak 4.2 btw >>> >>> ----------------- >>> Benoit St-Jean >>> Yahoo! Messenger: bstjean >>> A standpoint is an intellectual horizon of radius zero. >>> (Albert Einstein) >>> From: Ciprian Teodorov <[hidden email]> >>> To: [hidden email] >>> Sent: Saturday, December 8, 2012 11:11:44 AM >>> Subject: Re: [Pharo-project] strange == behavior >>> >>> by the way, we have the same thing in 1.0, 1.1, 1.3. >>> >>> On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <[hidden email]> wrote: >>> Hi guys, >>> >>> Playing with some recursive data-structure I have found some strange piece of behavior in Pharo. >>> >>> If in an workspace we try to evaluate: >>> >>> a := Association new. >>> a key: 3. >>> a value: a. >>> a == a value. >>> >>> the first time we get "true", the second we get an infinite loop... >>> >>> A simple workaround is to declare "a": >>> >>> |a| >>> a := Association new. >>> a key: 3. >>> a value: a. >>> a == a value. >>> >>> My question now is: Is this a bug or a feature ? >>> By the way the same thing happens in 1.4 and 2.0 equally. >>> >>> By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "." >>> >>> Cheers, >>> -- >>> Dr. Ciprian TEODOROV >>> Ingénieur Développement CAO >>> >>> tél : 06 08 54 73 48 >>> mail : [hidden email] >>> www.teodorov.ro >>> >>> >>> >>> -- >>> Dr. Ciprian TEODOROV >>> Ingénieur Développement CAO >>> >>> tél : 06 08 54 73 48 >>> mail : [hidden email] >>> www.teodorov.ro >>> >>> >>> >>> >>> >>> -- >>> Dr. Ciprian TEODOROV >>> Ingénieur Développement CAO >>> >>> tél : 06 08 54 73 48 >>> mail : [hidden email] >>> www.teodorov.ro >> >> > > -- Best regards, Igor Stasenko. |
|
|
On Dec 9, 2012, at 7:24 PM, Igor Stasenko <[hidden email]> wrote: > some years ago, its been a long discussion on squeak mailing list about that.. > imo association should compare keys. not values. > But it's not very clear why? Why should (1 -> 2) = (1 -> 4) be true? They are not the same! If you want to compare keys, you can easily write (1 -> 2) key = (1 -> 4) key and the people reading the code will directly understand what your intention is. Marcus > But self-referencing data structures is and will be a problem. And > there is no easy solution: > > a := Array new: 1. > a at:1 put: a. > > a = a > > On 9 December 2012 17:20, Sven Van Caekenberghe <[hidden email]> wrote: >> I am not pro, see my comments in the issue tracker. >> >> For example, >> >> | a | >> a := Association key: #foo. >> (a value: (Array with: a)) = (a value: (Array with: a)). >> >> would still loop. >> >> Loops like that cannot be prevented locally. >> >> See my other mail about prevent stack overflow. >> >> On 09 Dec 2012, at 16:32, Stéphane Ducasse <[hidden email]> wrote: >> >>> Hi guys >>> >>> what is the impact on method =? >>> Any ideas? >>> >>> Stef >>> On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote: >>> >>>> It seems that this issue can be fixed by modifying the = method in Association. >>>> >>>> Association>>= anAssociation >>>> ^ super = anAssociation >>>> and: [ >>>> value == anAssociation value >>>> ifTrue: [ true ] >>>> ifFalse: [ value = anAssociation value ] ] >>>> >>>> Cheers... >>>> >>>> On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <[hidden email]> wrote: >>>> Same behavior in Squeak 4.2 btw >>>> >>>> ----------------- >>>> Benoit St-Jean >>>> Yahoo! Messenger: bstjean >>>> A standpoint is an intellectual horizon of radius zero. >>>> (Albert Einstein) >>>> From: Ciprian Teodorov <[hidden email]> >>>> To: [hidden email] >>>> Sent: Saturday, December 8, 2012 11:11:44 AM >>>> Subject: Re: [Pharo-project] strange == behavior >>>> >>>> by the way, we have the same thing in 1.0, 1.1, 1.3. >>>> >>>> On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <[hidden email]> wrote: >>>> Hi guys, >>>> >>>> Playing with some recursive data-structure I have found some strange piece of behavior in Pharo. >>>> >>>> If in an workspace we try to evaluate: >>>> >>>> a := Association new. >>>> a key: 3. >>>> a value: a. >>>> a == a value. >>>> >>>> the first time we get "true", the second we get an infinite loop... >>>> >>>> A simple workaround is to declare "a": >>>> >>>> |a| >>>> a := Association new. >>>> a key: 3. >>>> a value: a. >>>> a == a value. >>>> >>>> My question now is: Is this a bug or a feature ? >>>> By the way the same thing happens in 1.4 and 2.0 equally. >>>> >>>> By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "." >>>> >>>> Cheers, >>>> -- >>>> Dr. Ciprian TEODOROV >>>> Ingénieur Développement CAO >>>> >>>> tél : 06 08 54 73 48 >>>> mail : [hidden email] >>>> www.teodorov.ro >>>> >>>> >>>> >>>> -- >>>> Dr. Ciprian TEODOROV >>>> Ingénieur Développement CAO >>>> >>>> tél : 06 08 54 73 48 >>>> mail : [hidden email] >>>> www.teodorov.ro >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Dr. Ciprian TEODOROV >>>> Ingénieur Développement CAO >>>> >>>> tél : 06 08 54 73 48 >>>> mail : [hidden email] >>>> www.teodorov.ro >>> >>> >> >> > > > > -- > Best regards, > Igor Stasenko. > |
|
|
In reply to this post by Igor Stasenko
Hi guys,
I agree that = can cause these kind of issues... But I found strange that == does too. IMHO i was hoping that object identity won't be tricked into this kind of loops, especially since it works on first evaluation...
Maybe the solution I have found is shallow (modifying the association =). But I think that the issue still holds. Maybe the problem is somewhere in the way the workspace implicit variables are handled or stored, if they will be stored in an identity dictionary maybe there won't be a problem. I don't know.
On Sun, Dec 9, 2012 at 7:24 PM, Igor Stasenko <[hidden email]> wrote: some years ago, its been a long discussion on squeak mailing list about that.. Dr. Ciprian TEODOROV Ingénieur Développement CAO tél : 06 08 54 73 48 mail : [hidden email] www.teodorov.ro |
|
|
As for the = method in Association (besides perverted side effects) I think that my code is at least logical.
If the keys are equal and the values hold absolutely the same object then it means the two associations are equal. If the values are not (object identity) equal then, and only then we should compare them with =
BTW this agrees with the point raised by Markus about comparing only keys ((1 -> 2) key = (1 -> 4) key).
On Sun, Dec 9, 2012 at 7:41 PM, Ciprian Teodorov <[hidden email]> wrote: Hi guys, Dr. Ciprian TEODOROV Ingénieur Développement CAO tél : 06 08 54 73 48 mail : [hidden email] www.teodorov.ro |
|
|
Also note that some implementors of = start with verifying == first, some not.
I would solve this differently by checking self == anObject in super (LookupKey). Nicolas 2012/12/9 Ciprian Teodorov <[hidden email]>: > As for the = method in Association (besides perverted side effects) I think > that my code is at least logical. > > If the keys are equal and the values hold absolutely the same object then it > means the two associations are equal. If the values are not (object > identity) equal then, and only then we should compare them with = > > BTW this agrees with the point raised by Markus about comparing only keys > ((1 -> 2) key = (1 -> 4) key). > > > On Sun, Dec 9, 2012 at 7:41 PM, Ciprian Teodorov > <[hidden email]> wrote: >> >> Hi guys, >> >> I agree that = can cause these kind of issues... But I found strange that >> == does too. IMHO i was hoping that object identity won't be tricked into >> this kind of loops, especially since it works on first evaluation... >> >> Maybe the solution I have found is shallow (modifying the association =). >> But I think that the issue still holds. Maybe the problem is somewhere in >> the way the workspace implicit variables are handled or stored, if they will >> be stored in an identity dictionary maybe there won't be a problem. I don't >> know. >> >> On Sun, Dec 9, 2012 at 7:24 PM, Igor Stasenko <[hidden email]> wrote: >>> >>> some years ago, its been a long discussion on squeak mailing list about >>> that.. >>> imo association should compare keys. not values. >>> >>> But self-referencing data structures is and will be a problem. And >>> there is no easy solution: >>> >>> a := Array new: 1. >>> a at:1 put: a. >>> >>> a = a >>> >>> On 9 December 2012 17:20, Sven Van Caekenberghe <[hidden email]> wrote: >>> > I am not pro, see my comments in the issue tracker. >>> > >>> > For example, >>> > >>> > | a | >>> > a := Association key: #foo. >>> > (a value: (Array with: a)) = (a value: (Array with: a)). >>> > >>> > would still loop. >>> > >>> > Loops like that cannot be prevented locally. >>> > >>> > See my other mail about prevent stack overflow. >>> > >>> > On 09 Dec 2012, at 16:32, Stéphane Ducasse <[hidden email]> >>> > wrote: >>> > >>> >> Hi guys >>> >> >>> >> what is the impact on method =? >>> >> Any ideas? >>> >> >>> >> Stef >>> >> On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote: >>> >> >>> >>> It seems that this issue can be fixed by modifying the = method in >>> >>> Association. >>> >>> >>> >>> Association>>= anAssociation >>> >>> ^ super = anAssociation >>> >>> and: [ >>> >>> value == anAssociation value >>> >>> ifTrue: [ true ] >>> >>> ifFalse: [ value = anAssociation value ] >>> >>> ] >>> >>> >>> >>> Cheers... >>> >>> >>> >>> On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <[hidden email]> >>> >>> wrote: >>> >>> Same behavior in Squeak 4.2 btw >>> >>> >>> >>> ----------------- >>> >>> Benoit St-Jean >>> >>> Yahoo! Messenger: bstjean >>> >>> A standpoint is an intellectual horizon of radius zero. >>> >>> (Albert Einstein) >>> >>> From: Ciprian Teodorov <[hidden email]> >>> >>> To: [hidden email] >>> >>> Sent: Saturday, December 8, 2012 11:11:44 AM >>> >>> Subject: Re: [Pharo-project] strange == behavior >>> >>> >>> >>> by the way, we have the same thing in 1.0, 1.1, 1.3. >>> >>> >>> >>> On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov >>> >>> <[hidden email]> wrote: >>> >>> Hi guys, >>> >>> >>> >>> Playing with some recursive data-structure I have found some strange >>> >>> piece of behavior in Pharo. >>> >>> >>> >>> If in an workspace we try to evaluate: >>> >>> >>> >>> a := Association new. >>> >>> a key: 3. >>> >>> a value: a. >>> >>> a == a value. >>> >>> >>> >>> the first time we get "true", the second we get an infinite loop... >>> >>> >>> >>> A simple workaround is to declare "a": >>> >>> >>> >>> |a| >>> >>> a := Association new. >>> >>> a key: 3. >>> >>> a value: a. >>> >>> a == a value. >>> >>> >>> >>> My question now is: Is this a bug or a feature ? >>> >>> By the way the same thing happens in 1.4 and 2.0 equally. >>> >>> >>> >>> By the way, in Pharo 2.0 doing cmd + . erases the lines selected in >>> >>> the workspace replacing them by "." >>> >>> >>> >>> Cheers, >>> >>> -- >>> >>> Dr. Ciprian TEODOROV >>> >>> Ingénieur Développement CAO >>> >>> >>> >>> tél : 06 08 54 73 48 >>> >>> mail : [hidden email] >>> >>> www.teodorov.ro >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Dr. Ciprian TEODOROV >>> >>> Ingénieur Développement CAO >>> >>> >>> >>> tél : 06 08 54 73 48 >>> >>> mail : [hidden email] >>> >>> www.teodorov.ro >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Dr. Ciprian TEODOROV >>> >>> Ingénieur Développement CAO >>> >>> >>> >>> tél : 06 08 54 73 48 >>> >>> mail : [hidden email] >>> >>> www.teodorov.ro >>> >> >>> >> >>> > >>> > >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> >> -- >> Dr. Ciprian TEODOROV >> Ingénieur Développement CAO >> >> tél : 06 08 54 73 48 >> mail : [hidden email] >> www.teodorov.ro > > > > > -- > Dr. Ciprian TEODOROV > Ingénieur Développement CAO > > tél : 06 08 54 73 48 > mail : [hidden email] > www.teodorov.ro |
|
|
On Dec 9, 2012, at 7:59 PM, Nicolas Cellier wrote: > Also note that some implementors of = start with verifying == first, some not. > I would solve this differently by checking self == anObject in super > (LookupKey). BTW in that case should not be LookupKey be called IdentityLookupKey > > Nicolas > > 2012/12/9 Ciprian Teodorov <[hidden email]>: >> As for the = method in Association (besides perverted side effects) I think >> that my code is at least logical. >> >> If the keys are equal and the values hold absolutely the same object then it >> means the two associations are equal. If the values are not (object >> identity) equal then, and only then we should compare them with = >> >> BTW this agrees with the point raised by Markus about comparing only keys >> ((1 -> 2) key = (1 -> 4) key). >> >> >> On Sun, Dec 9, 2012 at 7:41 PM, Ciprian Teodorov >> <[hidden email]> wrote: >>> >>> Hi guys, >>> >>> I agree that = can cause these kind of issues... But I found strange that >>> == does too. IMHO i was hoping that object identity won't be tricked into >>> this kind of loops, especially since it works on first evaluation... >>> >>> Maybe the solution I have found is shallow (modifying the association =). >>> But I think that the issue still holds. Maybe the problem is somewhere in >>> the way the workspace implicit variables are handled or stored, if they will >>> be stored in an identity dictionary maybe there won't be a problem. I don't >>> know. >>> >>> On Sun, Dec 9, 2012 at 7:24 PM, Igor Stasenko <[hidden email]> wrote: >>>> >>>> some years ago, its been a long discussion on squeak mailing list about >>>> that.. >>>> imo association should compare keys. not values. >>>> >>>> But self-referencing data structures is and will be a problem. And >>>> there is no easy solution: >>>> >>>> a := Array new: 1. >>>> a at:1 put: a. >>>> >>>> a = a >>>> >>>> On 9 December 2012 17:20, Sven Van Caekenberghe <[hidden email]> wrote: >>>>> I am not pro, see my comments in the issue tracker. >>>>> >>>>> For example, >>>>> >>>>> | a | >>>>> a := Association key: #foo. >>>>> (a value: (Array with: a)) = (a value: (Array with: a)). >>>>> >>>>> would still loop. >>>>> >>>>> Loops like that cannot be prevented locally. >>>>> >>>>> See my other mail about prevent stack overflow. >>>>> >>>>> On 09 Dec 2012, at 16:32, Stéphane Ducasse <[hidden email]> >>>>> wrote: >>>>> >>>>>> Hi guys >>>>>> >>>>>> what is the impact on method =? >>>>>> Any ideas? >>>>>> >>>>>> Stef >>>>>> On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote: >>>>>> >>>>>>> It seems that this issue can be fixed by modifying the = method in >>>>>>> Association. >>>>>>> >>>>>>> Association>>= anAssociation >>>>>>> ^ super = anAssociation >>>>>>> and: [ >>>>>>> value == anAssociation value >>>>>>> ifTrue: [ true ] >>>>>>> ifFalse: [ value = anAssociation value ] >>>>>>> ] >>>>>>> >>>>>>> Cheers... >>>>>>> >>>>>>> On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <[hidden email]> >>>>>>> wrote: >>>>>>> Same behavior in Squeak 4.2 btw >>>>>>> >>>>>>> ----------------- >>>>>>> Benoit St-Jean >>>>>>> Yahoo! Messenger: bstjean >>>>>>> A standpoint is an intellectual horizon of radius zero. >>>>>>> (Albert Einstein) >>>>>>> From: Ciprian Teodorov <[hidden email]> >>>>>>> To: [hidden email] >>>>>>> Sent: Saturday, December 8, 2012 11:11:44 AM >>>>>>> Subject: Re: [Pharo-project] strange == behavior >>>>>>> >>>>>>> by the way, we have the same thing in 1.0, 1.1, 1.3. >>>>>>> >>>>>>> On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov >>>>>>> <[hidden email]> wrote: >>>>>>> Hi guys, >>>>>>> >>>>>>> Playing with some recursive data-structure I have found some strange >>>>>>> piece of behavior in Pharo. >>>>>>> >>>>>>> If in an workspace we try to evaluate: >>>>>>> >>>>>>> a := Association new. >>>>>>> a key: 3. >>>>>>> a value: a. >>>>>>> a == a value. >>>>>>> >>>>>>> the first time we get "true", the second we get an infinite loop... >>>>>>> >>>>>>> A simple workaround is to declare "a": >>>>>>> >>>>>>> |a| >>>>>>> a := Association new. >>>>>>> a key: 3. >>>>>>> a value: a. >>>>>>> a == a value. >>>>>>> >>>>>>> My question now is: Is this a bug or a feature ? >>>>>>> By the way the same thing happens in 1.4 and 2.0 equally. >>>>>>> >>>>>>> By the way, in Pharo 2.0 doing cmd + . erases the lines selected in >>>>>>> the workspace replacing them by "." >>>>>>> >>>>>>> Cheers, >>>>>>> -- >>>>>>> Dr. Ciprian TEODOROV >>>>>>> Ingénieur Développement CAO >>>>>>> >>>>>>> tél : 06 08 54 73 48 >>>>>>> mail : [hidden email] >>>>>>> www.teodorov.ro >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Dr. Ciprian TEODOROV >>>>>>> Ingénieur Développement CAO >>>>>>> >>>>>>> tél : 06 08 54 73 48 >>>>>>> mail : [hidden email] >>>>>>> www.teodorov.ro >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Dr. Ciprian TEODOROV >>>>>>> Ingénieur Développement CAO >>>>>>> >>>>>>> tél : 06 08 54 73 48 >>>>>>> mail : [hidden email] >>>>>>> www.teodorov.ro >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >>> >>> -- >>> Dr. Ciprian TEODOROV >>> Ingénieur Développement CAO >>> >>> tél : 06 08 54 73 48 >>> mail : [hidden email] >>> www.teodorov.ro >> >> >> >> >> -- >> Dr. Ciprian TEODOROV >> Ingénieur Développement CAO >> >> tél : 06 08 54 73 48 >> mail : [hidden email] >> www.teodorov.ro > |
|
|
No, it's just a fast test, because if objects are == they also are =
(except Float nan). However, if they are ~~ they still can be =. If you look at SequenceableCollection>>= otherCollection "Answer true if the receiver is equivalent to the otherCollection. First test for identity, then rule out different species and sizes of collections. As a last resort, examine each element of the receiver and the otherCollection." self == otherCollection ifTrue: [^ true]. self species == otherCollection species ifFalse: [^ false]. ^ self hasEqualElements: otherCollection We could do the same with Association... LookupKey>>= aLookupKey self == aLookupKey ifTrue: [^ true]. self species = aLookupKey species ifTrue: [^key = aLookupKey key] ifFalse: [^false] Note that this has side effect for the sole object I know not equal to itself: | a | a := {Float nan}. a = a. "is true" a = {Float nan }. "is false" | a | a := #x -> Float nan. a = a. "is currently false but would be true after LookupKey change" a = #x -> Float nan. "false even after LookupKey change, true after Ciprian fix, but should it?" Nicolas 2012/12/9 Stéphane Ducasse <[hidden email]>: > > On Dec 9, 2012, at 7:59 PM, Nicolas Cellier wrote: > >> Also note that some implementors of = start with verifying == first, some not. >> I would solve this differently by checking self == anObject in super >> (LookupKey). > > BTW in that case should not be LookupKey be called IdentityLookupKey >> >> Nicolas >> >> 2012/12/9 Ciprian Teodorov <[hidden email]>: >>> As for the = method in Association (besides perverted side effects) I think >>> that my code is at least logical. >>> >>> If the keys are equal and the values hold absolutely the same object then it >>> means the two associations are equal. If the values are not (object >>> identity) equal then, and only then we should compare them with = >>> >>> BTW this agrees with the point raised by Markus about comparing only keys >>> ((1 -> 2) key = (1 -> 4) key). >>> >>> >>> On Sun, Dec 9, 2012 at 7:41 PM, Ciprian Teodorov >>> <[hidden email]> wrote: >>>> >>>> Hi guys, >>>> >>>> I agree that = can cause these kind of issues... But I found strange that >>>> == does too. IMHO i was hoping that object identity won't be tricked into >>>> this kind of loops, especially since it works on first evaluation... >>>> >>>> Maybe the solution I have found is shallow (modifying the association =). >>>> But I think that the issue still holds. Maybe the problem is somewhere in >>>> the way the workspace implicit variables are handled or stored, if they will >>>> be stored in an identity dictionary maybe there won't be a problem. I don't >>>> know. >>>> >>>> On Sun, Dec 9, 2012 at 7:24 PM, Igor Stasenko <[hidden email]> wrote: >>>>> >>>>> some years ago, its been a long discussion on squeak mailing list about >>>>> that.. >>>>> imo association should compare keys. not values. >>>>> >>>>> But self-referencing data structures is and will be a problem. And >>>>> there is no easy solution: >>>>> >>>>> a := Array new: 1. >>>>> a at:1 put: a. >>>>> >>>>> a = a >>>>> >>>>> On 9 December 2012 17:20, Sven Van Caekenberghe <[hidden email]> wrote: >>>>>> I am not pro, see my comments in the issue tracker. >>>>>> >>>>>> For example, >>>>>> >>>>>> | a | >>>>>> a := Association key: #foo. >>>>>> (a value: (Array with: a)) = (a value: (Array with: a)). >>>>>> >>>>>> would still loop. >>>>>> >>>>>> Loops like that cannot be prevented locally. >>>>>> >>>>>> See my other mail about prevent stack overflow. >>>>>> >>>>>> On 09 Dec 2012, at 16:32, Stéphane Ducasse <[hidden email]> >>>>>> wrote: >>>>>> >>>>>>> Hi guys >>>>>>> >>>>>>> what is the impact on method =? >>>>>>> Any ideas? >>>>>>> >>>>>>> Stef >>>>>>> On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote: >>>>>>> >>>>>>>> It seems that this issue can be fixed by modifying the = method in >>>>>>>> Association. >>>>>>>> >>>>>>>> Association>>= anAssociation >>>>>>>> ^ super = anAssociation >>>>>>>> and: [ >>>>>>>> value == anAssociation value >>>>>>>> ifTrue: [ true ] >>>>>>>> ifFalse: [ value = anAssociation value ] >>>>>>>> ] >>>>>>>> >>>>>>>> Cheers... >>>>>>>> >>>>>>>> On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <[hidden email]> >>>>>>>> wrote: >>>>>>>> Same behavior in Squeak 4.2 btw >>>>>>>> >>>>>>>> ----------------- >>>>>>>> Benoit St-Jean >>>>>>>> Yahoo! Messenger: bstjean >>>>>>>> A standpoint is an intellectual horizon of radius zero. >>>>>>>> (Albert Einstein) >>>>>>>> From: Ciprian Teodorov <[hidden email]> >>>>>>>> To: [hidden email] >>>>>>>> Sent: Saturday, December 8, 2012 11:11:44 AM >>>>>>>> Subject: Re: [Pharo-project] strange == behavior >>>>>>>> >>>>>>>> by the way, we have the same thing in 1.0, 1.1, 1.3. >>>>>>>> >>>>>>>> On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov >>>>>>>> <[hidden email]> wrote: >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> Playing with some recursive data-structure I have found some strange >>>>>>>> piece of behavior in Pharo. >>>>>>>> >>>>>>>> If in an workspace we try to evaluate: >>>>>>>> >>>>>>>> a := Association new. >>>>>>>> a key: 3. >>>>>>>> a value: a. >>>>>>>> a == a value. >>>>>>>> >>>>>>>> the first time we get "true", the second we get an infinite loop... >>>>>>>> >>>>>>>> A simple workaround is to declare "a": >>>>>>>> >>>>>>>> |a| >>>>>>>> a := Association new. >>>>>>>> a key: 3. >>>>>>>> a value: a. >>>>>>>> a == a value. >>>>>>>> >>>>>>>> My question now is: Is this a bug or a feature ? >>>>>>>> By the way the same thing happens in 1.4 and 2.0 equally. >>>>>>>> >>>>>>>> By the way, in Pharo 2.0 doing cmd + . erases the lines selected in >>>>>>>> the workspace replacing them by "." >>>>>>>> >>>>>>>> Cheers, >>>>>>>> -- >>>>>>>> Dr. Ciprian TEODOROV >>>>>>>> Ingénieur Développement CAO >>>>>>>> >>>>>>>> tél : 06 08 54 73 48 >>>>>>>> mail : [hidden email] >>>>>>>> www.teodorov.ro >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Dr. Ciprian TEODOROV >>>>>>>> Ingénieur Développement CAO >>>>>>>> >>>>>>>> tél : 06 08 54 73 48 >>>>>>>> mail : [hidden email] >>>>>>>> www.teodorov.ro >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Dr. Ciprian TEODOROV >>>>>>>> Ingénieur Développement CAO >>>>>>>> >>>>>>>> tél : 06 08 54 73 48 >>>>>>>> mail : [hidden email] >>>>>>>> www.teodorov.ro >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>>> >>>> -- >>>> Dr. Ciprian TEODOROV >>>> Ingénieur Développement CAO >>>> >>>> tél : 06 08 54 73 48 >>>> mail : [hidden email] >>>> www.teodorov.ro >>> >>> >>> >>> >>> -- >>> Dr. Ciprian TEODOROV >>> Ingénieur Développement CAO >>> >>> tél : 06 08 54 73 48 >>> mail : [hidden email] >>> www.teodorov.ro >> > > |
|
|
Ah, my mistake, modifying LookupKey does nothing to Association we
should move the == test in Associaiton itself... 2012/12/9 Nicolas Cellier <[hidden email]>: > No, it's just a fast test, because if objects are == they also are = > (except Float nan). > However, if they are ~~ they still can be =. > > If you look at SequenceableCollection>>= otherCollection > "Answer true if the receiver is equivalent to the otherCollection. > First test for identity, then rule out different species and sizes of > collections. As a last resort, examine each element of the receiver > and the otherCollection." > > self == otherCollection ifTrue: [^ true]. > self species == otherCollection species ifFalse: [^ false]. > ^ self hasEqualElements: otherCollection > > We could do the same with Association... > LookupKey>>= aLookupKey > > self == aLookupKey ifTrue: [^ true]. > self species = aLookupKey species > ifTrue: [^key = aLookupKey key] > ifFalse: [^false] > > Note that this has side effect for the sole object I know not equal to itself: > > | a | > a := {Float nan}. > a = a. "is true" > a = {Float nan }. "is false" > > | a | > a := #x -> Float nan. > a = a. "is currently false but would be true after LookupKey change" > a = #x -> Float nan. "false even after LookupKey change, true after > Ciprian fix, but should it?" > > Nicolas > > 2012/12/9 Stéphane Ducasse <[hidden email]>: >> >> On Dec 9, 2012, at 7:59 PM, Nicolas Cellier wrote: >> >>> Also note that some implementors of = start with verifying == first, some not. >>> I would solve this differently by checking self == anObject in super >>> (LookupKey). >> >> BTW in that case should not be LookupKey be called IdentityLookupKey >>> >>> Nicolas >>> >>> 2012/12/9 Ciprian Teodorov <[hidden email]>: >>>> As for the = method in Association (besides perverted side effects) I think >>>> that my code is at least logical. >>>> >>>> If the keys are equal and the values hold absolutely the same object then it >>>> means the two associations are equal. If the values are not (object >>>> identity) equal then, and only then we should compare them with = >>>> >>>> BTW this agrees with the point raised by Markus about comparing only keys >>>> ((1 -> 2) key = (1 -> 4) key). >>>> >>>> >>>> On Sun, Dec 9, 2012 at 7:41 PM, Ciprian Teodorov >>>> <[hidden email]> wrote: >>>>> >>>>> Hi guys, >>>>> >>>>> I agree that = can cause these kind of issues... But I found strange that >>>>> == does too. IMHO i was hoping that object identity won't be tricked into >>>>> this kind of loops, especially since it works on first evaluation... >>>>> >>>>> Maybe the solution I have found is shallow (modifying the association =). >>>>> But I think that the issue still holds. Maybe the problem is somewhere in >>>>> the way the workspace implicit variables are handled or stored, if they will >>>>> be stored in an identity dictionary maybe there won't be a problem. I don't >>>>> know. >>>>> >>>>> On Sun, Dec 9, 2012 at 7:24 PM, Igor Stasenko <[hidden email]> wrote: >>>>>> >>>>>> some years ago, its been a long discussion on squeak mailing list about >>>>>> that.. >>>>>> imo association should compare keys. not values. >>>>>> >>>>>> But self-referencing data structures is and will be a problem. And >>>>>> there is no easy solution: >>>>>> >>>>>> a := Array new: 1. >>>>>> a at:1 put: a. >>>>>> >>>>>> a = a >>>>>> >>>>>> On 9 December 2012 17:20, Sven Van Caekenberghe <[hidden email]> wrote: >>>>>>> I am not pro, see my comments in the issue tracker. >>>>>>> >>>>>>> For example, >>>>>>> >>>>>>> | a | >>>>>>> a := Association key: #foo. >>>>>>> (a value: (Array with: a)) = (a value: (Array with: a)). >>>>>>> >>>>>>> would still loop. >>>>>>> >>>>>>> Loops like that cannot be prevented locally. >>>>>>> >>>>>>> See my other mail about prevent stack overflow. >>>>>>> >>>>>>> On 09 Dec 2012, at 16:32, Stéphane Ducasse <[hidden email]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi guys >>>>>>>> >>>>>>>> what is the impact on method =? >>>>>>>> Any ideas? >>>>>>>> >>>>>>>> Stef >>>>>>>> On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote: >>>>>>>> >>>>>>>>> It seems that this issue can be fixed by modifying the = method in >>>>>>>>> Association. >>>>>>>>> >>>>>>>>> Association>>= anAssociation >>>>>>>>> ^ super = anAssociation >>>>>>>>> and: [ >>>>>>>>> value == anAssociation value >>>>>>>>> ifTrue: [ true ] >>>>>>>>> ifFalse: [ value = anAssociation value ] >>>>>>>>> ] >>>>>>>>> >>>>>>>>> Cheers... >>>>>>>>> >>>>>>>>> On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <[hidden email]> >>>>>>>>> wrote: >>>>>>>>> Same behavior in Squeak 4.2 btw >>>>>>>>> >>>>>>>>> ----------------- >>>>>>>>> Benoit St-Jean >>>>>>>>> Yahoo! Messenger: bstjean >>>>>>>>> A standpoint is an intellectual horizon of radius zero. >>>>>>>>> (Albert Einstein) >>>>>>>>> From: Ciprian Teodorov <[hidden email]> >>>>>>>>> To: [hidden email] >>>>>>>>> Sent: Saturday, December 8, 2012 11:11:44 AM >>>>>>>>> Subject: Re: [Pharo-project] strange == behavior >>>>>>>>> >>>>>>>>> by the way, we have the same thing in 1.0, 1.1, 1.3. >>>>>>>>> >>>>>>>>> On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov >>>>>>>>> <[hidden email]> wrote: >>>>>>>>> Hi guys, >>>>>>>>> >>>>>>>>> Playing with some recursive data-structure I have found some strange >>>>>>>>> piece of behavior in Pharo. >>>>>>>>> >>>>>>>>> If in an workspace we try to evaluate: >>>>>>>>> >>>>>>>>> a := Association new. >>>>>>>>> a key: 3. >>>>>>>>> a value: a. >>>>>>>>> a == a value. >>>>>>>>> >>>>>>>>> the first time we get "true", the second we get an infinite loop... >>>>>>>>> >>>>>>>>> A simple workaround is to declare "a": >>>>>>>>> >>>>>>>>> |a| >>>>>>>>> a := Association new. >>>>>>>>> a key: 3. >>>>>>>>> a value: a. >>>>>>>>> a == a value. >>>>>>>>> >>>>>>>>> My question now is: Is this a bug or a feature ? >>>>>>>>> By the way the same thing happens in 1.4 and 2.0 equally. >>>>>>>>> >>>>>>>>> By the way, in Pharo 2.0 doing cmd + . erases the lines selected in >>>>>>>>> the workspace replacing them by "." >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> -- >>>>>>>>> Dr. Ciprian TEODOROV >>>>>>>>> Ingénieur Développement CAO >>>>>>>>> >>>>>>>>> tél : 06 08 54 73 48 >>>>>>>>> mail : [hidden email] >>>>>>>>> www.teodorov.ro >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Dr. Ciprian TEODOROV >>>>>>>>> Ingénieur Développement CAO >>>>>>>>> >>>>>>>>> tél : 06 08 54 73 48 >>>>>>>>> mail : [hidden email] >>>>>>>>> www.teodorov.ro >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Dr. Ciprian TEODOROV >>>>>>>>> Ingénieur Développement CAO >>>>>>>>> >>>>>>>>> tél : 06 08 54 73 48 >>>>>>>>> mail : [hidden email] >>>>>>>>> www.teodorov.ro >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Dr. Ciprian TEODOROV >>>>> Ingénieur Développement CAO >>>>> >>>>> tél : 06 08 54 73 48 >>>>> mail : [hidden email] >>>>> www.teodorov.ro >>>> >>>> >>>> >>>> >>>> -- >>>> Dr. Ciprian TEODOROV >>>> Ingénieur Développement CAO >>>> >>>> tél : 06 08 54 73 48 >>>> mail : [hidden email] >>>> www.teodorov.ro >>> >> >> |
|
|
In reply to this post by Marcus Denker-4
On 9 December 2012 19:34, Marcus Denker <[hidden email]> wrote:
> > On Dec 9, 2012, at 7:24 PM, Igor Stasenko <[hidden email]> wrote: > >> some years ago, its been a long discussion on squeak mailing list about that.. >> imo association should compare keys. not values. >> > > But it's not very clear why? Why should > > (1 -> 2) = (1 -> 4) > > be true? They are not the same! > if you need to use associations outside of dicts, why not just using simple arrays? #(1 2) = #( 1 4) or ask yourself, why then we need a distinct class for associations, if its behavior is same as for collection of 2 elements? Lets then just rewrite Dictionary to use array first / array second instead of association key / value. > If you want to compare keys, you can easily write > > (1 -> 2) key = (1 -> 4) key > > and the people reading the code will directly understand what your intention is. > if we follow this, then all comparison methods in system should be implemented to always compare all fields for equality, without exception. Otherwise you risking to confuse people a lot ! :) > Marcus -- Best regards, Igor Stasenko. |
|
|
In reply to this post by Nicolas Cellier
What downsides would be to doing...
Float>>nan ^ NaN copy. Nicolas Cellier wrote: > No, it's just a fast test, because if objects are == they also are = > (except Float nan). > However, if they are ~~ they still can be =. > > If you look at SequenceableCollection>>= otherCollection > "Answer true if the receiver is equivalent to the otherCollection. > First test for identity, then rule out different species and sizes of > collections. As a last resort, examine each element of the receiver > and the otherCollection." > > self == otherCollection ifTrue: [^ true]. > self species == otherCollection species ifFalse: [^ false]. > ^ self hasEqualElements: otherCollection > > We could do the same with Association... > LookupKey>>= aLookupKey > > self == aLookupKey ifTrue: [^ true]. > self species = aLookupKey species > ifTrue: [^key = aLookupKey key] > ifFalse: [^false] > > Note that this has side effect for the sole object I know not equal to itself: > > | a | > a := {Float nan}. > a = a. "is true" > a = {Float nan }. "is false" > > | a | > a := #x -> Float nan. > a = a. "is currently false but would be true after LookupKey change" > a = #x -> Float nan. "false even after LookupKey change, true after > Ciprian fix, but should it?" > > Nicolas > > 2012/12/9 Stéphane Ducasse <[hidden email]>: > >> On Dec 9, 2012, at 7:59 PM, Nicolas Cellier wrote: >> >> >>> Also note that some implementors of = start with verifying == first, some not. >>> I would solve this differently by checking self == anObject in super >>> (LookupKey). >>> >> BTW in that case should not be LookupKey be called IdentityLookupKey >> >>> Nicolas >>> >>> 2012/12/9 Ciprian Teodorov <[hidden email]>: >>> >>>> As for the = method in Association (besides perverted side effects) I think >>>> that my code is at least logical. >>>> >>>> If the keys are equal and the values hold absolutely the same object then it >>>> means the two associations are equal. If the values are not (object >>>> identity) equal then, and only then we should compare them with = >>>> >>>> BTW this agrees with the point raised by Markus about comparing only keys >>>> ((1 -> 2) key = (1 -> 4) key). >>>> >>>> >>>> On Sun, Dec 9, 2012 at 7:41 PM, Ciprian Teodorov >>>> <[hidden email]> wrote: >>>> >>>>> Hi guys, >>>>> >>>>> I agree that = can cause these kind of issues... But I found strange that >>>>> == does too. IMHO i was hoping that object identity won't be tricked into >>>>> this kind of loops, especially since it works on first evaluation... >>>>> >>>>> Maybe the solution I have found is shallow (modifying the association =). >>>>> But I think that the issue still holds. Maybe the problem is somewhere in >>>>> the way the workspace implicit variables are handled or stored, if they will >>>>> be stored in an identity dictionary maybe there won't be a problem. I don't >>>>> know. >>>>> >>>>> On Sun, Dec 9, 2012 at 7:24 PM, Igor Stasenko <[hidden email]> wrote: >>>>> >>>>>> some years ago, its been a long discussion on squeak mailing list about >>>>>> that.. >>>>>> imo association should compare keys. not values. >>>>>> >>>>>> But self-referencing data structures is and will be a problem. And >>>>>> there is no easy solution: >>>>>> >>>>>> a := Array new: 1. >>>>>> a at:1 put: a. >>>>>> >>>>>> a = a >>>>>> >>>>>> On 9 December 2012 17:20, Sven Van Caekenberghe <[hidden email]> wrote: >>>>>> >>>>>>> I am not pro, see my comments in the issue tracker. >>>>>>> >>>>>>> For example, >>>>>>> >>>>>>> | a | >>>>>>> a := Association key: #foo. >>>>>>> (a value: (Array with: a)) = (a value: (Array with: a)). >>>>>>> >>>>>>> would still loop. >>>>>>> >>>>>>> Loops like that cannot be prevented locally. >>>>>>> >>>>>>> See my other mail about prevent stack overflow. >>>>>>> >>>>>>> On 09 Dec 2012, at 16:32, Stéphane Ducasse <[hidden email]> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>>> Hi guys >>>>>>>> >>>>>>>> what is the impact on method =? >>>>>>>> Any ideas? >>>>>>>> >>>>>>>> Stef >>>>>>>> On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote: >>>>>>>> >>>>>>>> >>>>>>>>> It seems that this issue can be fixed by modifying the = method in >>>>>>>>> Association. >>>>>>>>> >>>>>>>>> Association>>= anAssociation >>>>>>>>> ^ super = anAssociation >>>>>>>>> and: [ >>>>>>>>> value == anAssociation value >>>>>>>>> ifTrue: [ true ] >>>>>>>>> ifFalse: [ value = anAssociation value ] >>>>>>>>> ] >>>>>>>>> >>>>>>>>> Cheers... >>>>>>>>> >>>>>>>>> On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <[hidden email]> >>>>>>>>> wrote: >>>>>>>>> Same behavior in Squeak 4.2 btw >>>>>>>>> >>>>>>>>> ----------------- >>>>>>>>> Benoit St-Jean >>>>>>>>> Yahoo! Messenger: bstjean >>>>>>>>> A standpoint is an intellectual horizon of radius zero. >>>>>>>>> (Albert Einstein) >>>>>>>>> From: Ciprian Teodorov <[hidden email]> >>>>>>>>> To: [hidden email] >>>>>>>>> Sent: Saturday, December 8, 2012 11:11:44 AM >>>>>>>>> Subject: Re: [Pharo-project] strange == behavior >>>>>>>>> >>>>>>>>> by the way, we have the same thing in 1.0, 1.1, 1.3. >>>>>>>>> >>>>>>>>> On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov >>>>>>>>> <[hidden email]> wrote: >>>>>>>>> Hi guys, >>>>>>>>> >>>>>>>>> Playing with some recursive data-structure I have found some strange >>>>>>>>> piece of behavior in Pharo. >>>>>>>>> >>>>>>>>> If in an workspace we try to evaluate: >>>>>>>>> >>>>>>>>> a := Association new. >>>>>>>>> a key: 3. >>>>>>>>> a value: a. >>>>>>>>> a == a value. >>>>>>>>> >>>>>>>>> the first time we get "true", the second we get an infinite loop... >>>>>>>>> >>>>>>>>> A simple workaround is to declare "a": >>>>>>>>> >>>>>>>>> |a| >>>>>>>>> a := Association new. >>>>>>>>> a key: 3. >>>>>>>>> a value: a. >>>>>>>>> a == a value. >>>>>>>>> >>>>>>>>> My question now is: Is this a bug or a feature ? >>>>>>>>> By the way the same thing happens in 1.4 and 2.0 equally. >>>>>>>>> >>>>>>>>> By the way, in Pharo 2.0 doing cmd + . erases the lines selected in >>>>>>>>> the workspace replacing them by "." >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> -- >>>>>>>>> Dr. Ciprian TEODOROV >>>>>>>>> Ingénieur Développement CAO >>>>>>>>> >>>>>>>>> tél : 06 08 54 73 48 >>>>>>>>> mail : [hidden email] >>>>>>>>> www.teodorov.ro >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Dr. Ciprian TEODOROV >>>>>>>>> Ingénieur Développement CAO >>>>>>>>> >>>>>>>>> tél : 06 08 54 73 48 >>>>>>>>> mail : [hidden email] >>>>>>>>> www.teodorov.ro >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Dr. Ciprian TEODOROV >>>>>>>>> Ingénieur Développement CAO >>>>>>>>> >>>>>>>>> tél : 06 08 54 73 48 >>>>>>>>> mail : [hidden email] >>>>>>>>> www.teodorov.ro >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko. >>>>>> >>>>>> >>>>> -- >>>>> Dr. Ciprian TEODOROV >>>>> Ingénieur Développement CAO >>>>> >>>>> tél : 06 08 54 73 48 >>>>> mail : [hidden email] >>>>> www.teodorov.ro >>>>> >>>> >>>> -- >>>> Dr. Ciprian TEODOROV >>>> Ingénieur Développement CAO >>>> >>>> tél : 06 08 54 73 48 >>>> mail : [hidden email] >>>> www.teodorov.ro >>>> >> > > > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |