What is equivalence? (was: The Trunk: Collections-eem.603.mcz)

On Wed, Feb 4, 2015 at 1:12 PM, Chris Muller <[hidden email]> wrote:
>> On Wed, Feb 4, 2015 at 9:07 AM, Chris Muller <[hidden email]> wrote:
>>>
>>> isSequenceable is a term that refers to a particular *kind* of
>>> Collection, a sequenceable one.
>>>
>>> Therefore, IMO, I am unable to think of any more clear and explicit
>>> way of expressing that than "isKindOf: SequenceableCollection"...
>>
>>
>> self isCollection and: [self isSequenceable]  is better.  isKinfOf: is a)
>> not object-oriented as it forces an argument to be in a particular hierarchy
>> rather than having a particular interface, and b) is horribly inefficient,
>> causing a potentially long search of an object's class hierarchy.  isKindOf:
>> doesn't just smell, it stinks.
>
> Yes, and class-testing via #class as well, for the same reasons.  But
> sometimes we really do want to know whether we have a _particular
> implementation_ of a Dictionary, not just dictionary behaviors and
> API's.

Eliots subStrings: change is obviously a fine improvement and I think
the hasEqualElements: is too with one of Levente's suggestions.  But
may we scrutinize this change to Dictionary>>#= just a bit more?

Everyone agrees using #isDictionary is faster and more OO and less
smelly than isKindOf: Dictionary.

If #isDictionary refers to particular API and behaviors, one could
argue that a BTree should answer true to #isDictionary, because it has
similar API and behaviors.  In the context of _equivalence testing_
though, a BTree is not a Dictionary.

So as long as we interpret the various #isSomeType methods as truly of
*that type* (same semantics as isKindOf:), and not "similar to", then
I can see no side-effects (unless someone added #isDictionary to
BTree, of course).  However, we may want to visit the other #=
implementations elsewhere in the system too, unless this would appear
to be an inconsistency producing its own odor of sorts.

>> If #isDictionary refers to particular API and behaviors, one could
>> argue that a BTree should answer true to #isDictionary, because it has
>> similar API and behaviors.  In the context of _equivalence testing_
>> though, a BTree is not a Dictionary.
>>
>> So as long as we interpret the various #isSomeType methods as truly of
>> *that type* (same semantics as isKindOf:), and not "similar to", then
>> I can see no side-effects (unless someone added #isDictionary to
>> BTree, of course).  However, we may want to visit the other #=
>> implementations elsewhere in the system too, unless this would appear
>> to be an inconsistency producing its own odor of sorts.
>
> "similar to" is vague.  I *don't* interpret isFoo methods as isKindOf: (and
> think that most experienced Smalltalk programmers don't either).
> In
> Smalltalk type = protocol.  So these methods imply that an object implements
> a given set of messages, not that they are of any given class.

Then I am very interested to know your thoughts about my BTree
question, above, which shares the same protocol as Dictionary.  Should

    (BTree new at: 3 put: 'three'; yourself) = (Dictionary new at: 3
put: 'three'; yourself)

return true?  Why or why not?

>> >> If #isDictionary refers to particular API and behaviors, one could
>> >> argue that a BTree should answer true to #isDictionary, because it has
>> >> similar API and behaviors.  In the context of _equivalence testing_
>> >> though, a BTree is not a Dictionary.
>> >>
>> >> So as long as we interpret the various #isSomeType methods as truly of
>> >> *that type* (same semantics as isKindOf:), and not "similar to", then
>> >> I can see no side-effects (unless someone added #isDictionary to
>> >> BTree, of course).  However, we may want to visit the other #=
>> >> implementations elsewhere in the system too, unless this would appear
>> >> to be an inconsistency producing its own odor of sorts.
>> >
>> > "similar to" is vague.  I *don't* interpret isFoo methods as isKindOf:
>> > (and
>> > think that most experienced Smalltalk programmers don't either).
>> > In
>> > Smalltalk type = protocol.  So these methods imply that an object
>> > implements
>> > a given set of messages, not that they are of any given class.
>>
>> Then I am very interested to know your thoughts about my BTree
>> question, above, which shares the same protocol as Dictionary.  Should
>>
>>     (BTree new at: 3 put: 'three'; yourself) = (Dictionary new at: 3
>> put: 'three'; yourself)
>>
>> return true?  Why or why not?
>
> Duck typing applies here, if it quacks like a duck.  So if your BTree
> behaves like a Dictionary to the extent that e.g. MethodDictionary does
> (MethodDictionary supports associationAt: but isn't answering an association
> within it cuz it does't contain associations) then sure, it's a Dictionary.

I do not wish to be argumentative, but does a WeakArray quack like an
Array?  Not only does WeakArray share exactly the same API, but even
inherits from Array and "is-a" Array.  So why shouldn't this be true?

    (Array with: 1 with: 2 with: 3) = (WeakArray with: 1 with: 2 with:
3)   "false"

I think the answer is because #= (not any other method, just #=) needs
to care about which _implementation_ of the argument which is passed
when considering true equivalence to another object.

I agree we human developers can consider unequal but same-quacking
objects interchangeable in our fuzzy minds when we design our
applications, and that is powerful, however, *within the system*, I
just it needs #= to make implementation-specific distinctions,
especially for as base-classes as Array and Dictionary.

This seems to be reflected by most of the #= implementations in the
system, which check either #class, #species, or #isKindOf:.