"Samuel Tardieu" <sam at rfc1149.net> wrote:
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Wednesday, September 22, 2004 12:01 PM
Subject: Re: #perform:#orSendTo: question


> >>>>> "lex" == lex  <lex at cc.gatech.edu> writes:
> 
> lex> Why isn't the message going to the right object to begin with?
> 
> Good question, I'm still looking for the answer :)
> 
in an earlier mail about the same subject, Samuel wrote:

> Can I find somewhere an explanation of how this selector is
> supposed  to be used?
Its main purpose is support for menues. The MouseMenuController
gives the model a chance to perform a selected activity, but it will
perform a default activity when the model refuses to do something.

This is in MouseMenuController>>pluggableYellowButtonActivity.
Here, the menu is sent the message  invokeOn: model orSendTo: self.
#invokeOn:orSendTo:  has only two implementors, the
CustomMenu and the SelectionMenu.
The CustomMenu uses   

  recipient perform: aSelector orSendTo: alternateServiceProvider

and the SelectionMenu implements delegation to the most 
suitable service provider with this statement:

  (targetObject respondsTo: aSelector)
     ifTrue:
       [targetObject perform: aSelector]
     ifFalse:
       [anObject perform: aSelector]

This is your proposal again.


Most implementors  of  #perform:orSendTo:
are in fact models that provide support for some
(or all) of their menue options.

Note that Model, the superclass of most application
models, has this definition:

  perform: selector orSendTo: otherTarget
   "Selector was just chosen from a menu by a user.
     If can respond, then perform it on myself.
     If not, send it to otherTarget, presumably the
     editPane from which the menu was invoked." 

  "default is that the editor does all"
  ^ otherTarget perform: selector.



That is, the default behaviour of a model is to
refuse responsibility for the menu items!

I am not aware of uses of  #perform:orSendTo:
that are not related to menues.

Greetings,
Boris