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

I'm not saying I'm against your change, I'm just saying that I feel
this kind of "cleaning" should be done with deliberation and careful
consideration, not whimsically.  Today all of the #= implementations
in the system are based on type coherence, except for this one which
was just changed.  It's easier than it seems for semantics to be
subtly changed.

For example, I have several of my own dictionary implementations which
do not inherit from Dictionary; but if they implement #isDictionary
for a different reason, I will now get a different answer from #=
depending on which I ask it; (aDictionary = theirSpecialDictionary)
vs. (theirSpecialDictionary = aDictionary) might produce different
results if SpecialDictionary is doing the conventional "type" check.

> So what do you prefer Chris, making isSequenceable an Object method too, or
> using self isCollection and: [self isSequenceable]?  I like the former
> because its simple, but you might have valid objections to extending Object.
> That's why I'm canvassing opinions.  I wont stop nuking isKindOf:'s as I see
> them though ;-)

I prefer the latter because its asking if its a particular sub-types
require a super-type check first.  I think if you want simplicity you
should implement #isSequenceableCollection on Object to return the
"self isCollection and: [self isSequenceable]".

Because another consideration is consumption of the method namespace
on Object with simple terms that then become unavailable to
applications.  The most egregious example I can think of is
Object>>#name.  It means an app implement #name without overriding the
one in Object.  But every app has things that have #names.  There is a
remote possibility that an app might want to implement the
#isSequenceable for a application-specific purpose..