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 <nicolas.cellier.aka.nice@gmail.com> 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 <frank.shearar@gmail.com>:
>> 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 <hernan.wilkinson@10pines.com>
>> 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
>> <nicolas.cellier.aka.nice@gmail.com> 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 <hernan.wilkinson@10pines.com>:
>>>> 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: hernan.wilkinson@10Pines.com
>>>> 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: hernan.wilkinson@10Pines.com
>> site: http://www.10Pines.com
>> Address: Alem 693, Floor 5 B, Buenos Aires, Argentina
>>
>