commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: [lang] Moving parts of patterns to lang
Date Tue, 05 Nov 2002 17:37:59 GMT

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


On Tue, 5 Nov 2002, Steve Downey wrote:

> Why repeat Collections mistake? A closure is a language mechanism. It doesn't
> imply a Command interface at all. In Java, inner classes are effectively
> closures, they encapsulate the state of the VM where they are instantiated.
>
> Saying things like
>
> public class MyClass implements Closure
>
> is just nonsensical. It's not a closure. Calling it one doesn't make it so.
>
>
> On Tuesday 05 November 2002 11:47 am, Henri Yandell wrote:
> > 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 scolebourne@btopenworld.com wrote:
> > > (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
> > >
> > > >  from:    Henri Yandell <bayard@generationjava.com>
> > > > I'd like to kick off a discussion on moving some parts of [patterns]
> > > > over to [lang]. The parts in question are:
> > > >
> > > > Predicate - Object -> boolean
> > > > Transformer - Object -> Object
> > > > Command - Object -> void
> > > > Factory - void -> Object
> > > >
> > > > The parts not in scope are:
> > > >
> > > > Beans
> > > > Identifier
> > > >
> > > > The reasoning for the move is that the above four sub-packages are now
> > > > mature, and would be of use to both the Collections and IO codebases.
> > > > All four sub-packages above would get promoted into:
> > > >
> > > > org.apache.commons.lang.functor.
> > > >
> > > > which is what their equivalents in Collections are called. The ones in
> > > > Collections currently, Predicate, Transformer, Factory, would I assume
> > > > be deprecated in favour of the ones currently in Patterns.
> > > >
> > > > Collections currently calls the Command interface a Closure. We may
> > > > want to repeat this debate again.
> > > >
> > > > I'm not assuming that Collections would automatically be dependent on
> > > > these by the way, but it seems like a logical step. There has been some
> > > > concern over whether Collections should add yet another dependency, so
> > > > that would need to be broached later.
> > > >
> > > > Identifier and Bean might later move to Util or somesuch, or Patterns
> > > > would remain.
> > > >
> > > > Hen
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > > <mailto:commons-dev-unsubscribe@jakarta.apache.org> For additional
> > > > commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <mailto:commons-dev-unsubscribe@jakarta.apache.org> For additional
> > > commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message