On Sat, Jun 07, 2003 at 11:13:10AM -0700, Joel Shellman wrote:
> > On Sat, Jun 07, 2003 at 09:52:37AM -0700, Joel Shellman wrote:
> > <snip>
> > > How do you respond to the problem of inheritance? Having to traverse up
> the
> > > inheritance hierarchy seems way too expensive to me,
> >
> > Are you talking about traversing up the hierarchy to find the proper
> method
> > when a message is sent?  This seldom happens (< 5% of the time), since
> recently
> > invoked methods are cached at each call site.
> 
> No, I was referring to the code he was writing that had "check if I satisfy
> #Fooness and if not call super to see if it does".

Oops, sorry.  I jumped in on the thread pretty late.  Yes, that could be
an issue if the checks are done very frequently.  However, I'm not sure
how it compares to the cost of throwing and handling an exception, which
I would assume is significantly more expensive than a message send (I 
haven't benchmarked it, though).

> 
> > > and lacks flexbility.
> > > In fact, that proposal seems to be nearly indistinguishable from using
> > > #respondsTo. The "agreed upon symbol" would be a certain method. It's
> the
> > > same thing.
> > >
> > > What I am curious to know is why noone has discussed the idea of simply
> > > handling DNU exceptions if #isFoo isn't there. Why not? That seems to
> make
> > > some sense to me. I don't understand smalltalk exception handling,
> though,
> > > so I think I'll read up on that this morning.
> >
> > Because Smalltalkers tend to take naming of things seriously.  There
> > are many DNU hacks that can be done for many purposes, but if there is
> > another way, it is better to avoid polluting the "does not understand"
> > concept by using it for messages that the object actually does
> > understand.
> 
> I don't understand. I'm not talking about throwing a DNU if that's what you
> mean. I'm only talking about letting a DNU be thrown if the object doesn't
> have #isFoo. Ack! I see one of my problems, it's not a DNU, it's a
> MessageNotUnderstood that I should be talking about. Sorry!

Oh, that's a bit different than what I thought you meant.  I thought you
intended to change the definition of Object>>doesNotUnderstand: to allow
for #Fooness checking.

> Let's say I have a method that will process anything with  #Fooness but
> anything else it ignores. What about:
> 
> Processor>>process: anObject
>     [
>         anObject isFoo
>           ifTrue: [ Transcript show: 'Do the necessary processing'. ]
>           ifFalse: [ Transcript show: 'Do nothing'. ]
>     ]
>     on: MessageNotUnderstood
>     do: [
>         Transcript show: 'Could not process object so do nothing.'.
>     ]
> 
> How's that?

Not nearly as good as

Processor>>process: anObject
    anObject isFoo
      ifTrue: [ Transcript show: 'Do the necessary processing'. ]
      ifFalse: [ Transcript show: 'Do nothing'. ]

;-)


Joshua



> -joel
>