commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@centras.lt>
Subject Re: [pattern] Pattern charter, whats in, whats out
Date Sun, 11 Aug 2002 17:12:15 GMT

----- Original Message -----
From: "Stephen Colebourne" <scolebourne@btopenworld.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>;
<nicolaken@apache.org>
Sent: Sunday, August 11, 2002 6:53 PM
Subject: Re: [pattern] Pattern charter, whats in, whats out


> From: "Nicola Ken Barozzi" <nicolaken@apache.org>
> > From: <costinm@covalent.net>
> > > If you expect people to implement your interfaces - than commons is
not
> > > the right place ( IMO ). Try JCP or avalon.
>
> Sorry, this just makes no sense to me. Yes we should provide default
> implementations, but you seem to want to exclude all plugin points from
> commons!

I see it is impossible to decide:  "framework" or "plugin" or may be just
"callback".
I think we can keep [pattern] as minimalistic as possible  and add features
then it is requested by users.
[simplestore] has the same problem, it become a framework (was "simple") and
I do not know a god place for it.


>
> > I agree that a single project with interfaces is bad for commons, but
> > 1. pattern is about design patterns, not generic-convenient interfaces
>
> As someone else is bound to point out, there is little difference.
>
> > >>- convertors (couldn't find it on website), should be implementation
of
> > >>Transformer interface
> > >
> > > I don't think Transformer interface belongs to commons. Having a
> > > set of converters ( maybe some split from beanutils ) which may have
> > > a Transformer interface in it - is fine. Generic Transformer interface
> > > for other to implement - not here.
> >
> > As said erlier, IMHO "Transformer" is not a pattern, so I guess that it
> > could reside in a "transformer" package, as "Morpher" resides in
Morphos.
>
> Wrong. Converters are an implementation of Transformer. But Transformer
can
> be used for more than just convertors. The pre supplied TransformerUtils
> provided for a cloning transformer for example. And [collections] provides
> for applying a Transformer to all elements in a collection. Thus the
> Transformer interface is _shared_ between [collections] and [convertor].
(It
> isn't yet of course)
>
> > Ok, so let's say we agree that
> > 1. Commons must not have an "interface" package.
> > 2. Commons can define useful interfaces only in the context of a package
> > that gives one or more implementations
>
> Each interface in [pattern] already has 10 or more basic implementations.
> They just happen to be in a single Utils class.
>
> > Anyway, since commons is like it is already, and it works, I propose to
> > 1. remove all interfaces from "pattern" that do not define a clear
> > design pattern like the ones from the GOF.
> > 2. Put these interfaces in packages that implement them; a first
> > candidate: avalon-excalibur/converter for transformation.
> > 3. All interfaces that do not have a package that implements them can be
> > put in an empty package as a suggestion for future implementers, and
> > lifecycle stuff proposed to Avalon if deemed sensible.
> >
> > I think this is in the best interest of all.
>
> Not really. This approach leads to one project for each interface. The
> Predicate project would only have three classes for example. Yet it in
fact
> contains very useful functionality targetted for [collections],
[introspect]
> and [io]. This route would mean that [collections] would need to depend on
> _five_ extra projects [predicate], [transformer], [command], [factory] and
> [lang]. Madness.
>
> I'm not fussed whether they are in [pattern] or [lang], they just
shouldn't
> be in [collections] or some other higher level project.
>
> Stephen
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>


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