SortedCollection>>=
Locked
 
|
Hi,
I'm a little surprised with the current SortedCollection #= implementation... it is: = aSortedCollection "Answer true if my and aSortedCollection's species are the same,
and if our blocks are the same, and if our elements are the same." self species = aSortedCollection species ifFalse: [^ false].
sortBlock = aSortedCollection sortBlock ifTrue: [^ super = aSortedCollection] ifFalse: [^ false]
and my surprise is because it compares the sortBlocks that makes the simplest case to fail like this one: (SortedCollection sortBlock: [ :a :b | a < b ]) = (SortedCollection sortBlock: [ :a :b | a < b ])
One could argue that if we remove the sortBlock comparison then : (SortedCollection sortBlock: [ :a :b | a < b ]) = (SortedCollection sortBlock: [ :a :b | a > b ])
would return true... but is that wrong? ... or is the philosophy to use the message #hasEqualElements: on this cases? BTW, VisualWorks implementation is the same as pharo, but the BlockClosure>>= is different and that's why it works as at least I expected :-)
Bye, Hernan -- Hernán Wilkinson Agile Software Development, Teaching & Coaching Phone: +54 - 011 - 6091 - 3125
Mobile: +54 - 911 - 4470 - 7207 email: [hidden email] site: http://www.10Pines.com Address: Alem 693, Floor 5 B, Buenos Aires, Argentina |
|
|
Interesting...
We could ask such questions too with definition of - Heap equality (since they are partially sorted...) (Heap withAll: (1 to: 10) asArray) = (Heap withAll: (1 to: 10) asArray shuffled). - Interval equality, could you tell me which one is true? (3 to: 2) = (2 to: 1). (1 to: 7 by: 2) = (1 to: 8 by: 2). (1 to: 2 by: 2) = (1 to: 2 by: 3). Nicolas 2012/11/19 Hernan Wilkinson <[hidden email]>: > Hi, > I'm a little surprised with the current SortedCollection #= > implementation... it is: > > = aSortedCollection > "Answer true if my and aSortedCollection's species are the same, > and if our blocks are the same, and if our elements are the same." > > self species = aSortedCollection species ifFalse: [^ false]. > sortBlock = aSortedCollection sortBlock > ifTrue: [^ super = aSortedCollection] > ifFalse: [^ false] > > and my surprise is because it compares the sortBlocks that makes the > simplest case to fail like this one: > > (SortedCollection sortBlock: [ :a :b | a < b ]) = (SortedCollection > sortBlock: [ :a :b | a < b ]) > > One could argue that if we remove the sortBlock comparison then : > > (SortedCollection sortBlock: [ :a :b | a < b ]) = (SortedCollection > sortBlock: [ :a :b | a > b ]) > > would return true... but is that wrong? ... or is the philosophy to use the > message #hasEqualElements: on this cases? > > BTW, VisualWorks implementation is the same as pharo, but the > BlockClosure>>= is different and that's why it works as at least I expected > :-) > > Bye, > Hernan > > -- > Hernán Wilkinson > Agile Software Development, Teaching & Coaching > Phone: +54 - 011 - 6091 - 3125 > Mobile: +54 - 911 - 4470 - 7207 > email: [hidden email] > site: http://www.10Pines.com > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina > |
|
|
Interesting...
But then why (SortedCollection sortBlock: [ :a :b | a < b ]) = (SortedCollection sortBlock: [ :a :b | a < b ]) should return false?
Hernan
On Mon, Nov 19, 2012 at 5:54 PM, Nicolas Cellier <[hidden email]> wrote: Interesting... Hernán Wilkinson Agile Software Development, Teaching & Coaching Phone: +54 - 011 - 6091 - 3125
Mobile: +54 - 911 - 4470 - 7207 email: [hidden email] site: http://www.10Pines.com Address: Alem 693, Floor 5 B, Buenos Aires, Argentina |
|
|
I would guess because there is no general equality for anonymous functions. If the two collections used the same block (as opposed to equivalent blocks) I'd expect them to be =. frank
|
|
|
Certainly, but whether this behavior was designed on purpose or
casually due to difficulty of implementing closure equality is hard to tell. Even, with a "better" implementation of block closure, the notion of equality is not that clear... For example take (SortedCollection sortBlock: [:a :b l a < b]) = (SortedCollection sortBlock: [:a :b l b > a]). It might well answer false, even if they will sort any Interval the same. What I wanted to emphasize was more "is there a natural/canocical definition of object equality" If yes, I'm very interested, but I don't think so. If not, then we happen to have a collection of arbitrary definitions of equality. So, the question whether one definition is better than the other is difficult to answer. That's what I call interesting. I doubt we have explicit rationale, well written tests or standards (I didn't check ANSI) specifying the behaviour... We just have principles of least astonishment and principles of utility (is it used in the image, is it vital, etc...). Nicolas 2012/11/19 Frank Shearar <[hidden email]>: > I would guess because there is no general equality for anonymous functions. > If the two collections used the same block (as opposed to equivalent blocks) > I'd expect them to be =. > > frank > > On 19 Nov 2012, at 21:59, Hernan Wilkinson <[hidden email]> > wrote: > > Interesting... > > But then why (SortedCollection sortBlock: [ :a :b | a < b ]) = > (SortedCollection sortBlock: [ :a :b | a < b ]) should return false? > > Hernan > > > On Mon, Nov 19, 2012 at 5:54 PM, Nicolas Cellier > <[hidden email]> wrote: >> >> Interesting... >> >> We could ask such questions too with definition of >> - Heap equality (since they are partially sorted...) >> (Heap withAll: (1 to: 10) asArray) = (Heap withAll: (1 to: 10) >> asArray shuffled). >> - Interval equality, could you tell me which one is true? >> (3 to: 2) = (2 to: 1). >> (1 to: 7 by: 2) = (1 to: 8 by: 2). >> (1 to: 2 by: 2) = (1 to: 2 by: 3). >> >> Nicolas >> >> 2012/11/19 Hernan Wilkinson <[hidden email]>: >> > Hi, >> > I'm a little surprised with the current SortedCollection #= >> > implementation... it is: >> > >> > = aSortedCollection >> > "Answer true if my and aSortedCollection's species are the same, >> > and if our blocks are the same, and if our elements are the same." >> > >> > self species = aSortedCollection species ifFalse: [^ false]. >> > sortBlock = aSortedCollection sortBlock >> > ifTrue: [^ super = aSortedCollection] >> > ifFalse: [^ false] >> > >> > and my surprise is because it compares the sortBlocks that makes the >> > simplest case to fail like this one: >> > >> > (SortedCollection sortBlock: [ :a :b | a < b ]) = (SortedCollection >> > sortBlock: [ :a :b | a < b ]) >> > >> > One could argue that if we remove the sortBlock comparison then : >> > >> > (SortedCollection sortBlock: [ :a :b | a < b ]) = (SortedCollection >> > sortBlock: [ :a :b | a > b ]) >> > >> > would return true... but is that wrong? ... or is the philosophy to use >> > the >> > message #hasEqualElements: on this cases? >> > >> > BTW, VisualWorks implementation is the same as pharo, but the >> > BlockClosure>>= is different and that's why it works as at least I >> > expected >> > :-) >> > >> > Bye, >> > Hernan >> > >> > -- >> > Hernán Wilkinson >> > Agile Software Development, Teaching & Coaching >> > Phone: +54 - 011 - 6091 - 3125 >> > Mobile: +54 - 911 - 4470 - 7207 >> > email: [hidden email] >> > site: http://www.10Pines.com >> > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina >> > >> > > > > -- > Hernán Wilkinson > Agile Software Development, Teaching & Coaching > Phone: +54 - 011 - 6091 - 3125 > Mobile: +54 - 911 - 4470 - 7207 > email: [hidden email] > site: http://www.10Pines.com > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina > |
|
|
maybe I am just too naive, but to me this equality check is fairly simple:
- compare inner collection - compare block now of course we don't have a block compare, so I wrote a simple approximation: - compare block args / temp size - compare temps - compare block byte codes - check if the blocks are Clean (no outside references) in this case it is pretty safe to assume that the blocks are equal. On 2012-11-19, at 20:15, Nicolas Cellier <[hidden email]> wrote: > Certainly, but whether this behavior was designed on purpose or > casually due to difficulty of implementing closure equality is hard to > tell. > > Even, with a "better" implementation of block closure, the notion of > equality is not that clear... > For example take > (SortedCollection sortBlock: [:a :b l a < b]) = (SortedCollection > sortBlock: [:a :b l b > a]). > It might well answer false, even if they will sort any Interval the same. > > What I wanted to emphasize was more "is there a natural/canocical > definition of object equality" > If yes, I'm very interested, but I don't think so. > If not, then we happen to have a collection of arbitrary definitions > of equality. > So, the question whether one definition is better than the other is > difficult to answer. > That's what I call interesting. > I doubt we have explicit rationale, well written tests or standards (I > didn't check ANSI) specifying the behaviour... > We just have principles of least astonishment and principles of > utility (is it used in the image, is it vital, etc...). > > Nicolas > > 2012/11/19 Frank Shearar <[hidden email]>: >> I would guess because there is no general equality for anonymous functions. >> If the two collections used the same block (as opposed to equivalent blocks) >> I'd expect them to be =. >> >> frank >> >> On 19 Nov 2012, at 21:59, Hernan Wilkinson <[hidden email]> >> wrote: >> >> Interesting... >> >> But then why (SortedCollection sortBlock: [ :a :b | a < b ]) = >> (SortedCollection sortBlock: [ :a :b | a < b ]) should return false? >> >> Hernan >> >> >> On Mon, Nov 19, 2012 at 5:54 PM, Nicolas Cellier >> <[hidden email]> wrote: >>> >>> Interesting... >>> >>> We could ask such questions too with definition of >>> - Heap equality (since they are partially sorted...) >>> (Heap withAll: (1 to: 10) asArray) = (Heap withAll: (1 to: 10) >>> asArray shuffled). >>> - Interval equality, could you tell me which one is true? >>> (3 to: 2) = (2 to: 1). >>> (1 to: 7 by: 2) = (1 to: 8 by: 2). >>> (1 to: 2 by: 2) = (1 to: 2 by: 3). >>> >>> Nicolas >>> >>> 2012/11/19 Hernan Wilkinson <[hidden email]>: >>>> Hi, >>>> I'm a little surprised with the current SortedCollection #= >>>> implementation... it is: >>>> >>>> = aSortedCollection >>>> "Answer true if my and aSortedCollection's species are the same, >>>> and if our blocks are the same, and if our elements are the same." >>>> >>>> self species = aSortedCollection species ifFalse: [^ false]. >>>> sortBlock = aSortedCollection sortBlock >>>> ifTrue: [^ super = aSortedCollection] >>>> ifFalse: [^ false] >>>> >>>> and my surprise is because it compares the sortBlocks that makes the >>>> simplest case to fail like this one: >>>> >>>> (SortedCollection sortBlock: [ :a :b | a < b ]) = (SortedCollection >>>> sortBlock: [ :a :b | a < b ]) >>>> >>>> One could argue that if we remove the sortBlock comparison then : >>>> >>>> (SortedCollection sortBlock: [ :a :b | a < b ]) = (SortedCollection >>>> sortBlock: [ :a :b | a > b ]) >>>> >>>> would return true... but is that wrong? ... or is the philosophy to use >>>> the >>>> message #hasEqualElements: on this cases? >>>> >>>> BTW, VisualWorks implementation is the same as pharo, but the >>>> BlockClosure>>= is different and that's why it works as at least I >>>> expected >>>> :-) >>>> >>>> Bye, >>>> Hernan >>>> >>>> -- >>>> Hernán Wilkinson >>>> Agile Software Development, Teaching & Coaching >>>> Phone: +54 - 011 - 6091 - 3125 >>>> Mobile: +54 - 911 - 4470 - 7207 >>>> email: [hidden email] >>>> site: http://www.10Pines.com >>>> Address: Alem 693, Floor 5 B, Buenos Aires, Argentina >>>> >>> >> >> >> >> -- >> Hernán Wilkinson >> Agile Software Development, Teaching & Coaching >> Phone: +54 - 011 - 6091 - 3125 >> Mobile: +54 - 911 - 4470 - 7207 >> email: [hidden email] >> site: http://www.10Pines.com >> Address: Alem 693, Floor 5 B, Buenos Aires, Argentina >> > |
|
|
I think the problem is related to the fact that different objects can represent the same thing, as 1/2 that represents the same "final" number as 2/4, but you could also say that they are different, or 1 meter and 100 centimeters and different measures that represent the same distance, and so on.
So, an empty collection represents an empty collection no matter if it is a sorted one or not, and a SortedCollection with 1, 2 and 3 and sortblock a<b represents the same collection of elements as a SortedCollection with 1, 2 and 3 and block a<=b.
The problem is that the message #= is not enough. We should have more messages to represent the different "equivalent relationship" where equality is one of it. For example, one message could be #representsSameEntityAs: where 1 meter and 100 centimeter would return true, but 1 meter = 100 centimiter would return false (but I would not use the #= message for that, it is confusing).
Anyway, going back to the current problem, it is my opinion that with the current implementation of BlockClosure>>#= I would change how SortedCollection>>#= is implemented and use super #= implementation, because currently ((SortedCollection sortBlock: [:a :b | a < b ]) add: 1; add: 2; yourself) = ((SortedCollection sortBlock: [:a :b | a < b ]) add: 1; add: 2; yourself) returns false that is really really astonishing.... and least in other smalltalks returns true.
Hernan. On Mon, Nov 19, 2012 at 8:27 PM, Camillo Bruni <[hidden email]> wrote: maybe I am just too naive, but to me this equality check is fairly simple: Hernán Wilkinson Agile Software Development, Teaching & Coaching Phone: +54 - 011 - 6091 - 3125
Mobile: +54 - 911 - 4470 - 7207 email: [hidden email] site: http://www.10Pines.com Address: Alem 693, Floor 5 B, Buenos Aires, Argentina |
|
|
You should ask Norberto Manzanos, he implemented an IdentitySolver which mitigates the lack of these "philosophical" objects in Smalltalk. Besides he has real experience working with objects difficult to identify and compare. I don't think he's willing to share it with the Pharo community, but who knows... Cheers, Hernán El 19/11/2012 21:20, Hernan Wilkinson escribió: > I think the problem is related to the fact that different objects can > represent the same thing, as 1/2 that represents the same "final" number > as 2/4, but you could also say that they are different, or 1 meter and > 100 centimeters and different measures that represent the same distance, > and so on. > So, an empty collection represents an empty collection no matter if it > is a sorted one or not, and a SortedCollection with 1, 2 and 3 and > sortblock a<b represents the same collection of elements as a > SortedCollection with 1, 2 and 3 and block a<=b. > The problem is that the message #= is not enough. We should have more > messages to represent the different "equivalent relationship" where > equality is one of it. For example, one message could be > #representsSameEntityAs: where 1 meter and 100 centimeter would return > true, but 1 meter = 100 centimiter would return false (but I would not > use the #= message for that, it is confusing). > > Anyway, going back to the current problem, it is my opinion that with > the current implementation of BlockClosure>>#= I would change how > SortedCollection>>#= is implemented and use super #= > implementation, because currently ((SortedCollection sortBlock: [:a :b | > a < b ]) add: 1; add: 2; yourself) = ((SortedCollection sortBlock: [:a > :b | a < b ]) add: 1; add: 2; yourself) returns false that is > really really astonishing.... and least in other smalltalks returns true. > > Hernan. > > > On Mon, Nov 19, 2012 at 8:27 PM, Camillo Bruni <[hidden email] > <mailto:[hidden email]>> wrote: > > maybe I am just too naive, but to me this equality check is fairly > simple: > > - compare inner collection > - compare block > > now of course we don't have a block compare, so I wrote a simple > approximation: > > - compare block args / temp size > - compare temps > - compare block byte codes > - check if the blocks are Clean (no outside references) > > in this case it is pretty safe to assume that the blocks are equal. > > On 2012-11-19, at 20:15, Nicolas Cellier > <[hidden email] > <mailto:[hidden email]>> wrote: > > > Certainly, but whether this behavior was designed on purpose or > > casually due to difficulty of implementing closure equality is > hard to > > tell. > > > > Even, with a "better" implementation of block closure, the notion of > > equality is not that clear... > > For example take > > (SortedCollection sortBlock: [:a :b l a < b]) = (SortedCollection > > sortBlock: [:a :b l b > a]). > > It might well answer false, even if they will sort any Interval > the same. > > > > What I wanted to emphasize was more "is there a natural/canocical > > definition of object equality" > > If yes, I'm very interested, but I don't think so. > > If not, then we happen to have a collection of arbitrary definitions > > of equality. > > So, the question whether one definition is better than the other is > > difficult to answer. > > That's what I call interesting. > > I doubt we have explicit rationale, well written tests or > standards (I > > didn't check ANSI) specifying the behaviour... > > We just have principles of least astonishment and principles of > > utility (is it used in the image, is it vital, etc...). > > > > Nicolas > > > > 2012/11/19 Frank Shearar <[hidden email] > <mailto:[hidden email]>>: > >> I would guess because there is no general equality for anonymous > functions. > >> If the two collections used the same block (as opposed to > equivalent blocks) > >> I'd expect them to be =. > >> > >> frank > >> > >> On 19 Nov 2012, at 21:59, Hernan Wilkinson > <[hidden email] <mailto:[hidden email]>> > >> wrote: > >> > >> Interesting... > >> > >> But then why (SortedCollection sortBlock: [ :a :b | a < b ]) = > >> (SortedCollection sortBlock: [ :a :b | a < b ]) should return false? > >> > >> Hernan > >> > >> > >> On Mon, Nov 19, 2012 at 5:54 PM, Nicolas Cellier > >> <[hidden email] > <mailto:[hidden email]>> wrote: > >>> > >>> Interesting... > >>> > >>> We could ask such questions too with definition of > >>> - Heap equality (since they are partially sorted...) > >>> (Heap withAll: (1 to: 10) asArray) = (Heap withAll: (1 to: 10) > >>> asArray shuffled). > >>> - Interval equality, could you tell me which one is true? > >>> (3 to: 2) = (2 to: 1). > >>> (1 to: 7 by: 2) = (1 to: 8 by: 2). > >>> (1 to: 2 by: 2) = (1 to: 2 by: 3). > >>> > >>> Nicolas > >>> > >>> 2012/11/19 Hernan Wilkinson <[hidden email] > <mailto:[hidden email]>>: > >>>> Hi, > >>>> I'm a little surprised with the current SortedCollection #= > >>>> implementation... it is: > >>>> > >>>> = aSortedCollection > >>>> "Answer true if my and aSortedCollection's species are the same, > >>>> and if our blocks are the same, and if our elements are the same." > >>>> > >>>> self species = aSortedCollection species ifFalse: [^ false]. > >>>> sortBlock = aSortedCollection sortBlock > >>>> ifTrue: [^ super = aSortedCollection] > >>>> ifFalse: [^ false] > >>>> > >>>> and my surprise is because it compares the sortBlocks that > makes the > >>>> simplest case to fail like this one: > >>>> > >>>> (SortedCollection sortBlock: [ :a :b | a < b ]) = > (SortedCollection > >>>> sortBlock: [ :a :b | a < b ]) > >>>> > >>>> One could argue that if we remove the sortBlock comparison then : > >>>> > >>>> (SortedCollection sortBlock: [ :a :b | a < b ]) = > (SortedCollection > >>>> sortBlock: [ :a :b | a > b ]) > >>>> > >>>> would return true... but is that wrong? ... or is the > philosophy to use > >>>> the > >>>> message #hasEqualElements: on this cases? > >>>> > >>>> BTW, VisualWorks implementation is the same as pharo, but the > >>>> BlockClosure>>= is different and that's why it works as at least I > >>>> expected > >>>> :-) > >>>> > >>>> Bye, > >>>> Hernan > >>>> > >>>> -- > >>>> Hernán Wilkinson > >>>> Agile Software Development, Teaching & Coaching > >>>> Phone: +54 - 011 - 6091 - 3125 > >>>> Mobile: +54 - 911 - 4470 - 7207 > >>>> email: [hidden email] > >>>> site: http://www.10Pines.com > >>>> Address: Alem 693, Floor 5 B, Buenos Aires, Argentina > >>>> > >>> > >> > >> > >> > >> -- > >> Hernán Wilkinson > >> Agile Software Development, Teaching & Coaching > >> Phone: +54 - 011 - 6091 - 3125 > >> Mobile: +54 - 911 - 4470 - 7207 > >> email: [hidden email] > >> site: http://www.10Pines.com > >> Address: Alem 693, Floor 5 B, Buenos Aires, Argentina > >> > > > > > > > > -- > *Hernán Wilkinson > Agile Software Development, Teaching & Coaching* > *Phone: +54 - 011 - *6091 - 3125* > Mobile: +54 - 911 - 4470 - 7207 > email: [hidden email] > site: http://www.10Pines.com <http://www.10pines.com/>* > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina > |
|
|
In reply to this post by Hernan Wilkinson-3
hmm, imo block comparison is superfluous.
at the point of comparison, if two sorted collections happen to contain same elements with same order, i think, it is safe to assume them equal. the point is that block behavior influencing only the way how you add or remove elements from collection, as for the rest, collections will behave similar for all messages except from adding/deleting elements. but adding or deleting elements will immediately make them different, no matter what sort block is used. On 19 November 2012 16:59, Hernan Wilkinson <[hidden email]> wrote: > Hi, > I'm a little surprised with the current SortedCollection #= > implementation... it is: > > = aSortedCollection > "Answer true if my and aSortedCollection's species are the same, > and if our blocks are the same, and if our elements are the same." > > self species = aSortedCollection species ifFalse: [^ false]. > sortBlock = aSortedCollection sortBlock > ifTrue: [^ super = aSortedCollection] > ifFalse: [^ false] > > and my surprise is because it compares the sortBlocks that makes the > simplest case to fail like this one: > > (SortedCollection sortBlock: [ :a :b | a < b ]) = (SortedCollection > sortBlock: [ :a :b | a < b ]) > > One could argue that if we remove the sortBlock comparison then : > > (SortedCollection sortBlock: [ :a :b | a < b ]) = (SortedCollection > sortBlock: [ :a :b | a > b ]) > > would return true... but is that wrong? ... or is the philosophy to use the > message #hasEqualElements: on this cases? > > BTW, VisualWorks implementation is the same as pharo, but the > BlockClosure>>= is different and that's why it works as at least I expected > :-) > > Bye, > Hernan > > -- > Hernán Wilkinson > Agile Software Development, Teaching & Coaching > Phone: +54 - 011 - 6091 - 3125 > Mobile: +54 - 911 - 4470 - 7207 > email: [hidden email] > site: http://www.10Pines.com > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina > -- Best regards, Igor Stasenko. |
|
|
I completely agree.... your explanation is far much better than mine :-)
On Tue, Nov 20, 2012 at 2:28 AM, Igor Stasenko <[hidden email]> wrote: hmm, imo block comparison is superfluous. Hernán Wilkinson Agile Software Development, Teaching & Coaching Phone: +54 - 011 - 6091 - 3125
Mobile: +54 - 911 - 4470 - 7207 email: [hidden email] site: http://www.10Pines.com Address: Alem 693, Floor 5 B, Buenos Aires, Argentina |
|
|
Absolutely, it's as valid and as arbitrary as comparing blocks, so
effectively, opinions will vary. Personal opinion weighted by personal aura certainly is a possible criterion. SIMPLICITY could be one good criterion too (We ain't gonna need it). Especially when you consider cost of learning, documenting, maintaining, testing... Here, we can easily document the behaviour... Seems lot harder to justify utility / cost ratio though. Of course changing has a cost too, but Pharo is definitely willing to pay this price. 2012/11/20 Hernan Wilkinson <[hidden email]>: > I completely agree.... your explanation is far much better than mine :-) > > > On Tue, Nov 20, 2012 at 2:28 AM, Igor Stasenko <[hidden email]> wrote: >> >> hmm, imo block comparison is superfluous. >> at the point of comparison, if two sorted collections happen to >> contain same elements with same order, i think, it is safe to assume >> them equal. >> >> the point is that block behavior influencing only the way how you add >> or remove elements from collection, >> as for the rest, collections will behave similar for all messages >> except from adding/deleting elements. >> but adding or deleting elements will immediately make them different, >> no matter what sort block is used. >> Sure, they are equivalent thru #do: not necessarily thru #add: There will always be one message for which objects behaviour will vary, things like #identityHash. To be sure whether an object can safely replace another, we can still use #== primitive (fortunately the cost of replacement is then very cheap). Nicolas >> >> On 19 November 2012 16:59, Hernan Wilkinson >> <[hidden email]> wrote: >> > Hi, >> > I'm a little surprised with the current SortedCollection #= >> > implementation... it is: >> > >> > = aSortedCollection >> > "Answer true if my and aSortedCollection's species are the same, >> > and if our blocks are the same, and if our elements are the same." >> > >> > self species = aSortedCollection species ifFalse: [^ false]. >> > sortBlock = aSortedCollection sortBlock >> > ifTrue: [^ super = aSortedCollection] >> > ifFalse: [^ false] >> > >> > and my surprise is because it compares the sortBlocks that makes the >> > simplest case to fail like this one: >> > >> > (SortedCollection sortBlock: [ :a :b | a < b ]) = (SortedCollection >> > sortBlock: [ :a :b | a < b ]) >> > >> > One could argue that if we remove the sortBlock comparison then : >> > >> > (SortedCollection sortBlock: [ :a :b | a < b ]) = (SortedCollection >> > sortBlock: [ :a :b | a > b ]) >> > >> > would return true... but is that wrong? ... or is the philosophy to use >> > the >> > message #hasEqualElements: on this cases? >> > >> > BTW, VisualWorks implementation is the same as pharo, but the >> > BlockClosure>>= is different and that's why it works as at least I >> > expected >> > :-) >> > >> > Bye, >> > Hernan >> > >> > -- >> > Hernán Wilkinson >> > Agile Software Development, Teaching & Coaching >> > Phone: +54 - 011 - 6091 - 3125 >> > Mobile: +54 - 911 - 4470 - 7207 >> > email: [hidden email] >> > site: http://www.10Pines.com >> > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Hernán Wilkinson > Agile Software Development, Teaching & Coaching > Phone: +54 - 011 - 6091 - 3125 > Mobile: +54 - 911 - 4470 - 7207 > email: [hidden email] > site: http://www.10Pines.com > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |