Re: [lang] text subpackage [was: Boundaries of Lang RE: [lang] Tokenizer]

[Stephen Colebourne <sc...@btopenworld.com>]

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" <sc...@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" <ba...@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" <ba...@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