commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory" <ggreg...@seagullsoftware.com>
Subject RE: [lang] Boundaries of Lang RE: [lang] Tokenizer
Date Wed, 01 Sep 2004 18:13:41 GMT
So, should we rename Interpolation to MappedMessageFormat? I am +1.

Gary

> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Tuesday, August 31, 2004 18:20
> To: Jakarta Commons Developers List
> Subject: Re: [lang] Boundaries of Lang RE: [lang] Tokenizer
> 
> From: "Henri Yandell" <bayard@generationjava.com>
> > Interpolator is something I'm never too sure of in Lang (yes I know,
> I've
> > added it to Lang twice now). I use it or a similar class a lot, but
it's
> > very easy to implement in terms of StringUtils.replace; it can be
> > genericised all the way to Commons-EL and the word interpolate is
not
> > quite what it means in scripting languages (there's no access to the
> real
> > variable namespaces, just a pretend namespace in a Map).
> >
> > With DurationFormat, I've begun to think of Lang a little as an
entry
> > point into other libraries, along with being a java.lang set of
> utilities.
> >
> > So I think we're doing okay in terms of our boundaries, but I think
> > Interpolation is over the boundary. I'm +1 to declaring it a step
too
> far
> > and removing it for 2.1 (and changing the bugzilla entry to
WONTFIX).
> 
> I disagree. The fact that it has been asked for before, has
reoccurred,
> and
> that I use it (!) suggests that it is a useful utility class. [lang]
> should
> aim to include those classes that keep on being needed as low level
> utilities and we believe Java would benefit from. A
MappedMessageFormat is
> a
> good case, and is no more or less worthy than other classes in [lang].
> 
> Viewed in terms of the 'leads on to other libraries' model:
> - math subpackage --> [math]
> - time subpackage --> JodaTime
> - CharSetUtils/Interpolation --> [oro]/[regexp]
> 
> Stephen
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


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


Mime
View raw message