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.

Gulik.

-- 
http://gulik.pbwiki.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090630/74ba330f/attachment.htm