Generics

ducasse ducasse at iam.unibe.ch
Sat Oct 4 14:39:58 UTC 2003


Hi phil

may be you will find interesting the traits model....coming soon in 
Squeak
http://www.iam.unibe.ch/~scg/Research/Traits/index.html

stef

On Samedi, oct 4, 2003, at 16:21 Europe/Zurich, Phil Hudson wrote:

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



More information about the Squeak-dev mailing list