>On Fri, 3 Oct 2003, Phil Hudson wrote:
>
>> I do have a question though. Look what happens:
>>
>> anIhoTypesafeBag isKindOf: Bag.  "answers false"
>>
>> Now this is correct from the strict VM and class hierarchy point of view,
>> but false from the user's point of view. Did you consider overriding
>> #isKindOf: and decide against? If not, would it be right or wrong to write:
>>
>> IhoTypesafeBag>>isKindOf: aClass
>>     ^ bag isKindOf: aClass
>>
>> Would that break anything important that already exists? Please let me
>> know if I've misunderstood the semantics of #isKindOf: - I take it to be
>> cognate with Java's 'instanceOf' operator.
>
>It is cognate with instanceof, but that's a low level operation and should
>return a low level result.  

I'm unsure about the term "low level" in a Smalltalk context. Let's roll
with it for now. Perhaps you could give some it some more definition in a
follow-up.

>You should only be using #isKindOf: in the
>rare cases where you truly want to know which class an object has - in
>which case you would want to be able to tell the difference between a Bag
>and a TypesafeBag.  

I disagree. I would say that what you're describing is served by
Object>>#isMemberOf:. Object>>isKindOf: serves a related but different
purpose.

>In most cases, however, what you would want to do is
>send the object a message like #isBag - which is probably closer to asking
>an object in Java if it implements a particular interface 

You also do that using instanceof, of course.

>(see the comment
>for #isCollection, for example). There doesn't happen to be an #isBag in
>the image, which means that nobody has found it terribly useful to
>determine if an object is Bag-like yet, but it could easily be added.
>Overriding this method to return true would be your way of indicating "for
>all practical purposes, treat this object as a bag".

I can see that this would work, but it's not to my taste. It seems to me
to demand multiple re-implementations of identical functionality in
multiple classes, and in an ad-hoc and piecemeal way. My first reaction
is that seems like both poor design and poor implementation. What becomes
of the orthogonality of the Collections hierarchy? What about its
perceived consistency in the eyes of programmers?

Thanks for replying, you've given me some food for thought and a possible
solution - I hadn't thought of the #isBag approach. However, I think my
problem is essentially insoluble in Smalltalk. I put this down to the
lack of either multiple inheritance (yech) or interfaces (yay) in
Smalltalk. In fact, I would go so far as to make this contentious claim:
because of this lack, it is not possible to realize the Decorator design
pattern cleanly, correctly and completely in Smalltalk. That is, you can
never create a 100% transparently substitutable decorator object in
Smalltalk. (I notice the illustrative code in the GOF is in C++). I hope
I'm wrong about this, and that the real problem is just my boundless
ignorance. Anybody?