[squeak-dev] Re: What is equivalence? (was: The Trunk: Collections-eem.603.mcz)

Eliot Miranda eliot.miranda at gmail.com
Wed Feb 4 21:24:19 UTC 2015

On Wed, Feb 4, 2015 at 12:40 PM, Chris Muller <asqueaker at gmail.com> wrote:

> On Wed, Feb 4, 2015 at 1:12 PM, Chris Muller <ma.chris.m at gmail.com> wrote:
> >> On Wed, Feb 4, 2015 at 9:07 AM, Chris Muller <asqueaker at gmail.com>
> 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.

"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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150204/0a4e89ed/attachment.htm

More information about the Squeak-dev mailing list