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 <[email protected]> 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: [email protected] > site: http://www.10Pines.com > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina > -- Best regards, Igor Stasenko.
