[lang] Boundaries of Lang RE: [lang] Tokenizer

[Henri Yandell <ba...@generationjava.com>]

On Mon, 30 Aug 2004, Gary Gregory wrote:

> > -----Original Message-----
> > From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> > Sent: Saturday, August 28, 2004 05:05
> > To: Jakarta Commons Developers List
> > Subject: [lang] Tokenizer
> >
> >
> > I did wonder whether it might be better to create a commons-format at
> this
> > point. It could contain Tokenizer and Interpolator. The trouble is
> what
> > happens to FastDateFormat or DurationFormat? In the end, I felt it
> would
> > be
> > more confusing, we just need to control the formats we create.
>
> The boundaries of [lang] have been getting blurry. We are no longer
> "covering" java.lang. StringTokenizer is in java.util and we "cover" it
> in [lang]. I claim Interpolator "covers" java.text.MessageFormat which
> is yet in another package. We have a boat load of String routines in
> StringUtils. If we all agree that [lang] should do all things String
> then covering
>
> For Interpolator, I do not like the same, in a different thread I
> proposed some alternatives like MappedMessageFormat as a better version
> of java.text.MessageFormat.

I think we can happily claim that StringTokenizer is in the wrong place in
J2SE. In fact, I'm utterly of the opinion that java.util has no
justification for existence. There's not a single class in there that
shouldn't be elsewhere.

Timer and TimerTask are probably the most deserving to be in util, and
only because Sun time stuff is so i18nised it would be odd to mix them.

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).


Gary's suggested genericising is logical, but I'm not sure there's any
real use-case.

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.

The math subpackage offers some basic Commons Math things and needs to
contain lots of notes to look at that component as things get too limited,
DurationFormat is a nice entry point to nudge people to using JODA Time,
Enum and exception help get Java users into the features in later JDK's.
Validate also helps get people into the concepts of Assertions.


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).

Hen


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

Re: [lang] Boundaries of Lang RE: [lang] Tokenizer

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

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