2009/6/30 Michael van der Gulik <mikevdg at gmail.com>:
> Please reply under posts. It makes things less confusing.
>
>>
>>
>> On Jun 29, 2009, at 3:43 PM, David Goehrig wrote:
>>
>>> What I typically what I've been doing to eliminate all of these methods
>>> with a single simple change:
>>>
>>> Object
>>>   doesNoUnderstand: aMessage
>>>       ^ false
>
>
>>
>> On Tue, Jun 30, 2009 at 3:26 PM, Cameron Sanders
>> <csanders.personal at functional-analyst.com> wrote:
>> What you write (down below) is close to what I was thinking when I said
>> have all #isXXX return false by default;
>> although I would test that the first two characters match 'i' and 's' and
>> that more characters exist, if so, return false, otherwise, normal
>> #doesNotUnderstand: behavior.
>>
>> I would treat #is by itself differently... it is ... or it couldn't be
>> tested! So I would do nothing for simple #is. and I don't like #is: because
>> it looks like a class type test... but that is part of the point, eh?
>>
>> I'll have to go back to the original example (by siguctua at gmail.com, and
>> read more about lambdas) but I thought that CVLambda would implement
>> #isCVLambda  to return true when it can be verified to be one. The example
>> did not illustrate #doesNotUnderstand:.
>>
>> Back to the question of adding behavior to classes that you don't own.
>> VisualWorks has a means to extend a class in a different package ... as I
>> recall. As I recall, squeak has no such capability, right?
>>
>
> Squeak certainly has that capability, but I would discourage you from using
> it.
>
> Changing the implementation of doesNotUnderstand: is a code smell. You're
> starting to play with voodoo and you need a *very* good reason to do it.
> Otherwise you'll have made yourself a very difficult application to debug.
>
> In my opinion (which doubtless isn't shared by everyone here), base classes
> such as Object should not have a lot of >>isXXX methods. >>isBoolean and
>>>isString are okay (although I never use them), but >>isMorph or >>isColor
> or anything not related to the Kernel classes are pollution.
>
> If you're using an >>isXXX method, then your code probably needs
> refactoring. It means you're implementing class specific behaviour using
> conditional >>ifTrue: blocks. Typically, your code will be working with
> subclasses of a specific class, and you'd invoke polymorphic methods to get
> class specific behaviour rather than using conditional blocks such as
>>>ifTrue:, >>ifFalse: etc.
>
> If your code really does handle an object of any possible class (which is
> rare but does occur), then you can use >>isKindOf:, >>isMemberOf: and
>>>respondsTo:.
>
> Igor's lambda example was a bit complex for me to work through so I can't
> really comment on it.
>

Your suggestion is correct , except from situations like with my lambdas:

sometimes you need to differentiate a single kind of objects from the
rest of objects in universe.
isKindOf: doesn't helps , because then if we go that road , we're soon
will need
isKindOf:orOf:

simply because different objects could have same trait but belong to
different class hierarchies.

Concerning #respondsTo: - its also smells a bit, because you are
depending not on a specific behavior (by invoking some method) but
rather testing the class method dictionary, which is mostly static.
This approach (use of #respondsTo:) also doesn't fits well with
proxies (and we need them sometimes).

> Gulik.
>
> --
> http://gulik.pbwiki.com/
>


-- 
Best regards,
Igor Stasenko AKA sig.