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] text subpackage [was: Boundaries of Lang RE: [lang] Tokenizer]
Date Thu, 02 Sep 2004 17:44:22 GMT
+1 to o.a.c.lang.text

This is nice since MessageFormat is in java.text.

Gary

> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Thursday, September 02, 2004 01:05
> To: Jakarta Commons Developers List
> Subject: Re: [lang] text subpackage [was: Boundaries of Lang RE:
[lang]
> Tokenizer]
> 
> In fact, what I want to do is create a [lang] text subpackage. It
would
> contain Tokenizer and MappedMessageFormat, ie. the instantiated
classes.
> The
> main package has the static utility classes.
> 
> That way, users who want to pare down the library can remove the
> subpackage
> and re-jar. This should also be true of other subpackages like math
and
> enums (we should check this).
> 
> Stephen
> 
> ----- Original Message -----
> From: "Stephen Colebourne" <scolebourne@btopenworld.com>
> > +1 to the name
> > +1 to examining the digester code and taking the best/using it
> > +0 for 2.1 (meaning we can drop it for now if no-one does the work)
> >
> > Stephen
> >
> > ----- Original Message -----
> > From: "Henri Yandell" <bayard@generationjava.com>
> > > +1 to the name.
> > >
> > > Questions:
> > >
> > > which package?
> > > what about the Digester code?
> > > is this for 2.1?
> > >
> > > Hen
> > >
> > > On Wed, 1 Sep 2004, Gary Gregory wrote:
> > >
> > > > 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
> > > >
> > >
> > >
> > >
---------------------------------------------------------------------
> > > 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
> >
> 
> 
> ---------------------------------------------------------------------
> 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