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@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@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/