On Wed, Feb 4, 2015 at 4:49 PM, Chris Muller <ma.chris.m at gmail.com> wrote:

> >> >> 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"
>

IMO that's a bug.   And the bug is that WeakArray species = WeakArray,
whereas it should be Array.  If one selects/rejects/copies a WeakArray the
result is more useful if it is strong.  It would be interesting to make the
change and see what effect it has on the standard test suite.

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.
>

IMO the problem is because coming up with general purpose #=
implementations is hard.  You must have seen the controversy my definition
of CompiledMethod>>#= has caused over recent years.  #= has evolved a lot
since Smalltalk-80 as its been more affordable to be cleverer, but that
evolution also shows that its not absolutely obvious what #= should do; it
depends on context, and current definitions of #= are general agreements of
useful behaviour, some of these agreements having been made a long time ago.


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.
>

One thing #= should do is accept any object as an argument without error.
This wasn't always the case, but Smalltalk was not and never will be
perfect.  Apart from that, what #= means is something we have to
negotiate.  I don't think my recent changes broke anything.


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

Few of them use isKindOf:.  Some use class or species.  Some use #isFoo.  I
don't see that #isFoo is worse than #class or #species.  Do you think it is?



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150204/ff058f9e/attachment.htm