Re:is* specific class membership tests - Beginners Digest, Vol 21, Issue 27

Do I understand correctly that the main reason to use isMorph rather  
than is: Morph is that the former is faster. And is the reason to  
prefer is: Morph is that it is more robust against required changes  
in the code to accommodate other specific changes?

Wouldn't it be straightforward to use the is: * generic form and  
generate an automatic revision to the more specific form while  
providing a way to switch back whenever needed? Would such a system  
solve the problem discussed?

Offhand, optimizations for efficiency like this seem to me to be  
pretty easy to arrange and to undo with fairly simple "compilers".  
There are also tools which make creating such compilers quite easy.  
Here I think of a transformational attribute grammar (TAG) compiler  
which can create a working prototype language XX compiler in perhaps  
five times the volume of its Backus-Naur Form syntax.

Richard Karpinski, Nitpicker       dick@xxxxxxxx
148 Sequoia Circle, Santa Rosa, CA 95401
Home +1 707-546-6760     Cell +1 707-228-9716
http://cfcl.com/twiki/bin/view/Friends/Karpinski/WebHome

ps Put (or leave) "nitpicker" in the subject line to get past my spam  
filters.


On 2008, Jan 25, , at 4:00, Michael Rueger <m.rueger@xxxxxxx> wrote:

> > is: Class
> >    ^(self class) inheritsFrom: Class
>
> isKindOf: already exists.
>
> > which would never have to be overridden? Obviously there are some is*
> > methods that server a larger purpose but isn't  
> > more...polymorphic...to say
>
> is* is much much faster
>
> But, as I said, using is* is a sign of a design problem. If you use  
> is*
> you are hardwiring the knowledge about certain classes into your
> architecture.