From commons-dev-return-19167-qmlist-jakarta-archive-commons-dev=jakarta.apache.org@jakarta.apache.org Tue Nov 05 17:38:05 2002 Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 75593 invoked from network); 5 Nov 2002 17:38:05 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 5 Nov 2002 17:38:05 -0000 Received: (qmail 2500 invoked by uid 97); 5 Nov 2002 17:39:00 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 2440 invoked by uid 97); 5 Nov 2002 17:39:00 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 2383 invoked by uid 98); 5 Nov 2002 17:38:59 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Date: Tue, 5 Nov 2002 12:37:59 -0500 (EST) From: Henri Yandell X-X-Sender: To: Jakarta Commons Developers List Subject: Re: [lang] Moving parts of patterns to lang In-Reply-To: <200211051207.33185.steve.downey@netfolio.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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 > > > > 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: > > > > For additional > > > > commands, e-mail: > > > > > > -- > > > To unsubscribe, e-mail: > > > For additional > > > commands, e-mail: > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > > -- To unsubscribe, e-mail: For additional commands, e-mail: