commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [lang] Submission of Avalon.Excalibur.ThreadContext
Date Tue, 23 Jul 2002 20:37:27 GMT
From: "Henri Yandell" <bayard@generationjava.com>
> While I like frameworks, I'm not in favour of them in a core reusable jar
> like Commons.Lang. I don't think we should be expecting users to be
> extending classes just to use the functionality.

As a general rule, 'no frameworks' is probably right.

But then Enum is an extension point too. And I maintain that most of
[pattern] should be part of [lang] ;-) (Actually, Enum could have been part
of Pattern)...So its not that simple....

Here's how I view the boundary between [lang] framework and non [lang]
framework.
"Is there a pluggable policy kind of interface to something central??"

Enum [lang] and [pattern] Factory, Predicate, Transformer & Command are
simple extension points. They need no configuring to work. The [pattern]
interfaces provide standard implemetations accessed via a factory Utils
class, but that doesn't require configuration.

ThreadContext, CPUParser [avalon] and [pattern] Identifier & Immutable are
frameworks. They require more knowledge of their use, and both ThreadContext
and Identifier demonstrate this by having separate impl subpackages.

So, I would push against the second group being in [lang] but support the
first group. Thus no ThreadContext. It would seem to fit closer with
[threading], and with the CPU stuff.

Stephen


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


Mime
View raw message