On Thu, 14 Feb 2002, ducasse wrote:

[snip]
> My solution is like that
> 
> performAction
[snip]
>             argsGettingBlock isNil
>                 ifTrue: [model perform: actionSelector]
>                 ifFalse: [ | args|
>                         args := argsGettingBlock value.
>                         args isNil ifTrue: [^ self].
>                         model perform: actionSelector withArguments: args]]

Ah! That's interesting.

> Because what I need is the button that can perform action on another
> object and pass arguments to this object. 

Other than the model? My patch does this.

> However the arguments should
> not be specified at button creation but at button click.

Yes, that I don't do :) Interesting thought though.

I guess a fully general mechanism would let the model be dynamically
generated too. Hmm. Does your method allow for creation time arguments
specification? It looks like you must wrap it in a block. Hmm. That's a
bit inconsistent with menus, et al.

> So I was
> thinking passing a selector to get the arguments. However, the
> arguments can be generated from another object that the one receiving
> the actionSelector.

Yep. If the target can vary, you could have both the target and the
arguments (and the selector) determined by different objects, all at click
time!!!!!

(Perhaps I go too far. :))

> For example in the RegisteringFileList I need to call for example
> FileStream with fileIn and passing as argument the currently selected
> file. So this argument is asked to the fileList and serves as argument
> of the FileStream messages. So I chose to passa block.

Hmm. I'm not sure I'm following that example. The model of the button is
the FileStream? Or the RegisteringFileList? If the latter, shouldn't it
know its current selection?

I wonder if, with modules, we'll be less inclined to use blocks in these
sorts of situations, as opposed to having the client class just add some
methods.

> Furthermore, it
> may happen that the computation of the arguments just failed for
> contextual reason (in the file list that no file is selected) but
> still the action is performed. So I needed a way to cancel the action
> when the arguments were not satisfactory. So I pass a block which may
> return nil to cancel the arguments or should return an array.

This makes me thing that there should be a way to handle this with
exceptions, but, as always, I don't want to think of it :)

Cheers,
Bijan Parsia.