On Wednesday 06 November 2002 12:03 am, Henri Yandell wrote:
> 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
Executor is good as it's really unlikely to conflict with anyone else's name.
UnaryOperation also opens up BinaryOperation and thence
transform(Collection left, Collection right, Collection out, BinaryOperation);
It also frees Command up for a real command implementation.
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
