On Wed, 6 Nov 2002, Steve Downey wrote:
> 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);
Then unless you start a migh
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++};
> >
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 w
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;
//elsewhere
evaluate foo;
Of course, that's some other language. In java, anonymous inner classes
approximate closures:
I would think of a Closure as:
closure foo = { int i=0; i++ }
or some such. So you're right in that closure is not the right name.
But Command is also not the right name. The Command pattern implies Undo
and Argument and Results and not just:
public void do(Object).
Any other words?
Hen
I've pushed these into Lang under the name Functor.
Command is renamed to Closure to match Collections.
All tests pass.
Hen
On Tue, 5 Nov 2002 [EMAIL PROTECTED] wrote:
> (plus)1, I fully support this :-)) Predicate, Transformer,
> Command/Closure and Factory are very basic and mature, and fit
(plus)1, I fully support this :-)) Predicate, Transformer, Command/Closure and Factory
are very basic and mature, and fit well into [lang].
In addition this adds the ability to write a CloneUtils in [lang] very easily (as the
code already exists, it just needs a different front end).
Stephen
>
