On Tue, 5 Nov 2002, Steve Downey wrote:
> On Tuesday 05 November 2002 12:37 pm, Henri Yandell wrote:
> > I would think of a Closure as:
> >
> >
> > closure foo = { int i=0; i++ }
> >
> int i = 0;
> closure foo = {i++};
> return foo;
Good point. I'm utterly convinced that Closure is the wrong word as
there's no capture of state.
> > But Command is also not the right name. The Command pattern implies Undo
> > and Argument and Results and not just:
> >
>
> Command often has a subtype, Undoable, Nnot all commands are undoable.
> FileSave is a good example. You generally can't back out of that.
> CommitTransaction is another. Undoable adds unexecute(), which backs out what
> execute() does. Undo and redo is just walking up and down the command list.
>
> It does require that ALL the state be present in the Command for
> execution and unexection.
>
> > public void do(Object).
> >
>
> Traditionally, execute() doesn't take any arguments. They're supplied when the
> command object is created. It's a fairly old Smalltalk idiom. c.v. Design
> Patterns.
>
> >
> > Any other words?
> >
> I'm looking at what's in Collections now. It's neither a Closure or a Command.
> It's an UnaryOperation, or LambdaExpession. An unnamed function is applied to
> all elements in a collection.
How about Executor? This fits the style of Transformer [transform], though
we don't have Creator and Evaluator for Factory and Predicate.
[It also sounds like a nifty star destroyer]
I can accept Command, but I always feel that a full use of the Command
pattern is more than just the above [well, void do() I guess, as you've
pointed out the Object isn't required].
Hen
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
