Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 57687 invoked from network); 21 Nov 2002 21:09:40 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 21 Nov 2002 21:09:40 -0000 Received: (qmail 13274 invoked by uid 97); 21 Nov 2002 21:10:42 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 13222 invoked by uid 97); 21 Nov 2002 21:10:41 -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 13192 invoked by uid 98); 21 Nov 2002 21:10:40 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <004101c291a2$8fb18320$e97927d9@oemcomputer> From: "Stephen Colebourne" To: "Jakarta Commons Developers List" References: <20021121123951.40601.qmail@web10403.mail.yahoo.com> Subject: Re: [lang] Converters Date: Thu, 21 Nov 2002 21:11:29 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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 agree that something should go in [lang]. My proposal is that [lang] contains a 'convertor' subpackage that contains a factory to obtain a convertor, and implementations for String, Integer,(...Number), Date, Enum. ie. the basic types. Once this is settled, additional types can be considered. Stephen ----- Original Message ----- From: "Jeff Varszegi" > My Yahoo mail just burped and I don't think it sent my message, but I was attempting to email you > a reminder about this. I don't think we should let it go by the wayside. > > Jeff > > --- Ola Berg wrote: > > > I would prefer participation in NEW project [converter]. > > > [lang] is used only for general purpose functionality (if I understand > > > correctly). > > > In such case it would be possible to put some specific conversion > > > functionality. Not only for simple types. > > > > Wouldn't it be better if the base mechanisms for converter was in lang, together with > > conversions for simple types? The specific conversions belong IMO not in a converter package > > covering anything from Date to ImaginaryNumber to ResultSet to Money), but in the different > > specific packages where they are actually needed. A converter package containing specific > > conversions for many sorts of types would be too broad in scope. > > > > Instead, the converter mechanism in itself would be really lightweight, and you only need a > > dependency to lang (which you probably want anyway, given lang's general usefulness and small > > footprint). > > > > Another argument: If converter wasn't in lang, we would create cross dependencies, since chances > > are that lang can benefit from the basic conversion mechanisms, and that converter would benefit > > from lang (and needs to be dependent upon lang if the converter is a variant of Transformation > > which is a variant of Closure/Command/Whatever). > > > > Basic conversion could live happily in lang together with basic Predicate logic, other kinds of > > transformations etc. Conversion is such a basic pattern. > > > > /O > > > > > > -- > > To unsubscribe, e-mail: > > For additional commands, e-mail: > > > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > -- To unsubscribe, e-mail: For additional commands, e-mail: