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 <[email protected]>:
> 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 <[email protected]>
> 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
> <[email protected]> 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 <[email protected]>:
>> > 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
>> >
>>
>
>
>
> --
> 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
>

Reply via email to