You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2002/08/10 12:29:06 UTC
[pattern] Pattern charter, whats in, whats out
Ola asked on what criteria I would accept or reject patterns. Other
discussions have focussed on merging with [lang] or whether patterns are
appropriate for commons. So I thought I'd look into what has been coded so
far:
There are already groups appearing in [pattern]:
Group 1 - Utility patterns, like java.util.Comparator:
- Predicate, Command, Transformer, Factory, (ThrowableHandler)
They are intended to be implemented by an inner class, not a bean (what I
mean is that the implementing class will only implement this one method).
Thus they represent utility bits of code. These are already in commons
(collections) and Predicate will probably be used by IO
Group 2 - Marker interface patterns:
- Immutable, (also Null, Mutable, Bean ...)
These marker interfaces rely on something (ie. a framework) knowing about
them. For Immutable, I included ImmutableUtils to try to be a basic
framework. But it doesn't really work. The problem is that there is no clear
use case.
Group 3 -Bean style patterns:
- Identifiable, (also Resetable, Destroyable, Initializable,
StateChangeable, EmptyQueryable, Saveable, Loadable, ... the list could be
long, and you'll have to guess what some of these are about)
Unlike group 1, these are intended to be implemented by a bean, not an inner
class (what I mean is a proper class - one with a number of methods other
than those of the pattern interface). They allow that bean to perform
certain common behaviours in a standardised way.
My preference is thus as follows:
Group 1 becomes part of [lang]
Group 2 dies, unless Avalon is interested
Group 3 becomes [pattern], in the sandbox, not depended on, not in the
upcoming core.jar
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [pattern] Pattern charter, whats in, whats out
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen Colebourne wrote:
> From: "Costin Manolache" <cm...@yahoo.com>
>
>>>Group 1 - Utility patterns, like java.util.Comparator:
>>>- Predicate, Command, Transformer, Factory, (ThrowableHandler)
>>>They are intended to be implemented by an inner class, not a bean (what
>>
> I
>
>>>mean is that the implementing class will only implement this one
>>
> method).
>
>>>Thus they represent utility bits of code. These are already in commons
>>>(collections) and Predicate will probably be used by IO
>>
>>As long as they are clearly needed and used in the context of an
>>specific utility - it's fine. If Collections define a Predicate
>>that will be used to operate on the collection data - it's a perfect
>>use of an interface, and people using collections can use that
>>interface when they need to.
>
>
> I think this is where we differ. Predicate is already likely to be used by
> both [io] and [intropect]. It has applicability wider than just collections.
> Collections simply allows Predicate to be applied to collections. Similar
> arguments apply to Transformer, Command and Factory. Its just reuse of code.
I take the opportunity to calrify my previous +1.
I meant that I'm +1 for this type of stuff in pattern because design
patterns can be used anywhere in any project, not only in collections,
and they do not create a framework, as also Stephen has clearly showed.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [pattern] Pattern charter, whats in, whats out
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Costin Manolache" <cm...@yahoo.com>
> > Group 1 - Utility patterns, like java.util.Comparator:
> > - Predicate, Command, Transformer, Factory, (ThrowableHandler)
> > They are intended to be implemented by an inner class, not a bean (what
I
> > mean is that the implementing class will only implement this one
method).
> > Thus they represent utility bits of code. These are already in commons
> > (collections) and Predicate will probably be used by IO
>
> As long as they are clearly needed and used in the context of an
> specific utility - it's fine. If Collections define a Predicate
> that will be used to operate on the collection data - it's a perfect
> use of an interface, and people using collections can use that
> interface when they need to.
I think this is where we differ. Predicate is already likely to be used by
both [io] and [intropect]. It has applicability wider than just collections.
Collections simply allows Predicate to be applied to collections. Similar
arguments apply to Transformer, Command and Factory. Its just reuse of code.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [pattern] Pattern charter, whats in, whats out
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen Colebourne wrote:
> Well I don't want to be flamed, but...
>
> - configuration/parameters, but not the IoC interface, should be in commons
> [new project]
From a conceptual POV I tend to agree, but I won't bring this up on the
Avalon list, if you get what I mean ;-)
> - logger, but not the IoC interface, is in commons [logging]
We have our logging interface for many reasons, but I prefer not to
dwelve into it.
Recently Berin proposed to swith to a unique Logging interface between
Commons and Avalon IIRC, but it got turned down :-(
> - component/service lookup, but not the IoC interface, could be be in
> commons ([discovery] ??) but are probably more appropriate in Avalon
Discovery is a lightweight JNDI it seems...
> - activity, could be in commons [pattern]
-1
> - Enums/Exceptions, are in commons [lang]
+1
> - convertors (couldn't find it on website), should be implementation of
> Transformer interface
+1
> To make these changes would be controversial in commons, and may require
> incompatabilities in Avalon. Hardly desirable.
Unfortunatly what conceptually seems simple and elegant is hardly
practible, I agree :-/
> Two of the above are interesting - configuration and activity. I have code
> for configuration available which I would love to see in a new commons
> project. But its a matter of time..
Avalon has Configuration stuff it would be cool to be of general use.
Well, it *is* of general use, if someone doesn't mind being "infected"
by an avalon package.
> Activity is just a set of convenient interfaces. The scary part for some
> commons people is the belief that they _must_ be used in a framework, and
> that they imply a certain ordering, that they can't be used independently
> just on any old bean. This isn't my opinion, but I have no sense that
> lifecycle methods will arrive in commons anytime soon.
Activity interfaces are needed as part of a contract.
If you define the contract, you need a framework to support it if you
want the contract to be reused and general.
Or else, each Bean can have his own init() method or whatever.
I just don't see what the problem is about using the Avalon interfaces...
You want activity? Use Avalon interfaces, simple as that.
> Stephen
>
> PS: I've signed up to Avalon, but if the traffic is too high then I may have
> to stop
;-) Naaa, not ATM. And not as much as Commons.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [pattern] Pattern charter, whats in, whats out
Posted by Juozas Baliuka <ba...@centras.lt>.
----- Original Message -----
From: "Stephen Colebourne" <sc...@btopenworld.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
<ni...@apache.org>
Sent: Sunday, August 11, 2002 6:53 PM
Subject: Re: [pattern] Pattern charter, whats in, whats out
> From: "Nicola Ken Barozzi" <ni...@apache.org>
> > From: <co...@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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [pattern] Pattern charter, whats in, whats out
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Nicola Ken Barozzi" <ni...@apache.org>
> From: <co...@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 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [pattern] Pattern charter, whats in, whats out
Posted by Stephen Colebourne <sc...@btopenworld.com>.
[pattern] is about SHARING CODE. Its as simple as that.
Consider the Predicate interface. It returns a boolean result based on an
input object. The associated PredicateUtils allows these Predicates to be
chained using and, or, xor, not, any, all, one, none connections. 22
implementations already. [collections] allows a Predicate to be applied to
every element in a collection, except that its currently a different
Predicate interface. Thus unless collections adopts [pattern], all the
associated PredicateUtils classes will have to be recoded/copied/forked.
Now consider [io]. There there is a FileFilter that allows a file to be
filtered based on its name. In [io], some kind soul has written classes to
combine FileFilters using and, or & not. But a FileFilter is just an
interface that takes in an object and returns a boolean - its a _Predicate_.
By providing the relevant adaptors, all 22 of the predicate functions can be
used, rather than just the 3 currently written. And the code won't be
duplicated/forked etc.
Now consider [introspect]. OK so you can't because its not there yet, but...
One of the tasks of introspection is to decide if a method matches a
particular naming pattern. Thats Object in, boolean out. Its a Predicate.
And Ola has already written many implementations. By making those
implementations implement Predicate we gain the 22 basic Predicate
implementations already provided.
Similar cases can be made for the other [pattern] interfaces.
I'm sorry if I sound a little preachy. This just seems soooooo simple to me.
- Write code once
- Locate it in one central place
- Locate it independent of the higher level projects
At the moment it feels like I'm just banging my head against a wall :-((
Stephen
----- Original Message -----
From: "Nicola Ken Barozzi" <ni...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Sunday, August 11, 2002 4:33 PM
Subject: Re: [pattern] Pattern charter, whats in, whats out
> costinm@covalent.net wrote:
> > Let me try again:
> >
> > If you expect people to use your code like an util/tool, than commons
> > may be the right place.
> >
> > If you expect people to implement your interfaces - than commons is not
> > the right place ( IMO ). Try JCP or avalon.
> >
> > At least I'll likely vote -1 on a proposal for commons that:
> > - doesn't do one specific and well defined task.
> > - requires a project to change it's design/API if it wants to use it.
> > - doesn't have a clear use in at least one jakarta project, with chances
> > that more projects will use it in future.
> >
> > I don't think commons is the place to define interfaces for the sake of
> > interfaces. We have 100s of interfaces only in JCP.
> >
> >
> >>- configuration/parameters, but not the IoC interface, should be in
commons
> >>[new project]
> >
> > Expect my -1 if you are thinking of interfaces.
> > There is already at least one APIs defined for that: JMX
> > ( and avalon has it's own mechanism ).
> >
> > Utils and helpers for configuration are ok ( I was thinking to decouple
> > the ant RuntimeConfigurable and making it a standalone util ).
>
> The point is that usually packages in commons implement an interface
> they specify. And that becomes the reference interface anyway.
>
> I agree that a single project with interfaces is bad for commons, but
> 1. pattern is about design patterns, not generic-convenient interfaces
> 2. there are already projects in commons that define interfaces, like
> commons-logging and commons-discovery, etc
>
> >>- component/service lookup, but not the IoC interface, could be be in
> >>commons ([discovery] ??) but are probably more appropriate in Avalon
> >
> > -1 for commons. We have JNDI and JMX for lookup, plus several other
> > interfaces.
>
> Hey, what about commons-discovery?
>
> >>- activity, could be in commons [pattern]
> >
> > What is 'activity' ?
>
> lifeycle. I'm also -1 for it.
>
> >>- Enums/Exceptions, are in commons [lang]
> >
> >
> > I personally think enums should be in collections - but in any case
> > as long as they are 'utils' you use, not new interfaces ( Iterator is
> > just fine for interface ). I think commons is ok.
>
> +1
>
> >>- 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.
>
> >>Two of the above are interesting - configuration and activity. I have
code
> >>for configuration available which I would love to see in a new commons
> >>project. But its a matter of time..
> >
> >
> > I suggest you first find a jakarta project and get it to use the code,
and
> > then consider proposing it for commons. Each project has it's own config
> > mechanism and tools - I would be happy to see few factored out and moved
> > to commons, but I'll strongly oppose creating one 'just in case someone
> > needs it'.
>
> +1
>
> >>Activity is just a set of convenient interfaces. The scary part for some
> >>commons people is the belief that they _must_ be used in a framework,
and
> >>that they imply a certain ordering, that they can't be used
independently
> >>just on any old bean. This isn't my opinion, but I have no sense that
> >>lifecycle methods will arrive in commons anytime soon.
> >
> >
> > Sorry for using the word 'framework'.
> >
> > I don't think commons is the place for creating 'convenient interfaces'.
>
> 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
>
> The problem that I see is that these interfaces still become a sort of
> important API... look at what happened to Commons logging...
>
> 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.
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [pattern] Pattern charter, whats in, whats out
Posted by Nicola Ken Barozzi <ni...@apache.org>.
costinm@covalent.net wrote:
> Let me try again:
>
> If you expect people to use your code like an util/tool, than commons
> may be the right place.
>
> If you expect people to implement your interfaces - than commons is not
> the right place ( IMO ). Try JCP or avalon.
>
> At least I'll likely vote -1 on a proposal for commons that:
> - doesn't do one specific and well defined task.
> - requires a project to change it's design/API if it wants to use it.
> - doesn't have a clear use in at least one jakarta project, with chances
> that more projects will use it in future.
>
> I don't think commons is the place to define interfaces for the sake of
> interfaces. We have 100s of interfaces only in JCP.
>
>
>>- configuration/parameters, but not the IoC interface, should be in commons
>>[new project]
>
> Expect my -1 if you are thinking of interfaces.
> There is already at least one APIs defined for that: JMX
> ( and avalon has it's own mechanism ).
>
> Utils and helpers for configuration are ok ( I was thinking to decouple
> the ant RuntimeConfigurable and making it a standalone util ).
The point is that usually packages in commons implement an interface
they specify. And that becomes the reference interface anyway.
I agree that a single project with interfaces is bad for commons, but
1. pattern is about design patterns, not generic-convenient interfaces
2. there are already projects in commons that define interfaces, like
commons-logging and commons-discovery, etc
>>- component/service lookup, but not the IoC interface, could be be in
>>commons ([discovery] ??) but are probably more appropriate in Avalon
>
> -1 for commons. We have JNDI and JMX for lookup, plus several other
> interfaces.
Hey, what about commons-discovery?
>>- activity, could be in commons [pattern]
>
> What is 'activity' ?
lifeycle. I'm also -1 for it.
>>- Enums/Exceptions, are in commons [lang]
>
>
> I personally think enums should be in collections - but in any case
> as long as they are 'utils' you use, not new interfaces ( Iterator is
> just fine for interface ). I think commons is ok.
+1
>>- 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.
>>Two of the above are interesting - configuration and activity. I have code
>>for configuration available which I would love to see in a new commons
>>project. But its a matter of time..
>
>
> I suggest you first find a jakarta project and get it to use the code, and
> then consider proposing it for commons. Each project has it's own config
> mechanism and tools - I would be happy to see few factored out and moved
> to commons, but I'll strongly oppose creating one 'just in case someone
> needs it'.
+1
>>Activity is just a set of convenient interfaces. The scary part for some
>>commons people is the belief that they _must_ be used in a framework, and
>>that they imply a certain ordering, that they can't be used independently
>>just on any old bean. This isn't my opinion, but I have no sense that
>>lifecycle methods will arrive in commons anytime soon.
>
>
> Sorry for using the word 'framework'.
>
> I don't think commons is the place for creating 'convenient interfaces'.
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
The problem that I see is that these interfaces still become a sort of
important API... look at what happened to Commons logging...
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.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [pattern] Pattern charter, whats in, whats out
Posted by co...@covalent.net.
Let me try again:
If you expect people to use your code like an util/tool, than commons
may be the right place.
If you expect people to implement your interfaces - than commons is not
the right place ( IMO ). Try JCP or avalon.
At least I'll likely vote -1 on a proposal for commons that:
- doesn't do one specific and well defined task.
- requires a project to change it's design/API if it wants to use it.
- doesn't have a clear use in at least one jakarta project, with chances
that more projects will use it in future.
I don't think commons is the place to define interfaces for the sake of
interfaces. We have 100s of interfaces only in JCP.
> - configuration/parameters, but not the IoC interface, should be in commons
> [new project]
Expect my -1 if you are thinking of interfaces.
There is already at least one APIs defined for that: JMX
( and avalon has it's own mechanism ).
Utils and helpers for configuration are ok ( I was thinking to decouple
the ant RuntimeConfigurable and making it a standalone util ).
> - component/service lookup, but not the IoC interface, could be be in
> commons ([discovery] ??) but are probably more appropriate in Avalon
-1 for commons. We have JNDI and JMX for lookup, plus several other
interfaces.
> - activity, could be in commons [pattern]
What is 'activity' ?
> - Enums/Exceptions, are in commons [lang]
I personally think enums should be in collections - but in any case
as long as they are 'utils' you use, not new interfaces ( Iterator is
just fine for interface ). I think commons is ok.
> - 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.
> Two of the above are interesting - configuration and activity. I have code
> for configuration available which I would love to see in a new commons
> project. But its a matter of time..
I suggest you first find a jakarta project and get it to use the code, and
then consider proposing it for commons. Each project has it's own config
mechanism and tools - I would be happy to see few factored out and moved
to commons, but I'll strongly oppose creating one 'just in case someone
needs it'.
> Activity is just a set of convenient interfaces. The scary part for some
> commons people is the belief that they _must_ be used in a framework, and
> that they imply a certain ordering, that they can't be used independently
> just on any old bean. This isn't my opinion, but I have no sense that
> lifecycle methods will arrive in commons anytime soon.
Sorry for using the word 'framework'.
I don't think commons is the place for creating 'convenient interfaces'.
Costin
>
> Stephen
>
> PS: I've signed up to Avalon, but if the traffic is too high then I may have
> to stop
>
> ----- Original Message -----
> From: "Nicola Ken Barozzi" <ni...@apache.org>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Saturday, August 10, 2002 7:40 PM
> Subject: Re: [pattern] Pattern charter, whats in, whats out
>
>
> > BTW, Stephen, sorry if I've been a bit too harsh in the last mails.
> > I think that many of the concepts things you are trying to do re in
> > Avalon, so I really invite you over to our list and project, you could
> > be a valid support :-)
> >
> > Besides, if you could help me out in resolving once and for all the
> > right separation and mix between Avalon and Commons, it would be awesome.
> > Hint: We have a CascadingException.
> > Lang has NestableException.
> > What to do about it?
> >
> > Also, we have a "converter" package in Excalubur that could go in
> > Commons maybe, as an implementation of the Transformer pattern.
> > Take a look at it, and let me know.
> >
> > Now for your reply :-)
> >
> >
> > Stephen Colebourne wrote:
> > > From: "Nicola Ken Barozzi" <ni...@apache.org>
> > >
> > >> pattern==design patterns
> > >> pattern!=just common interfaces
> > >
> > >
> > > Predicate, Transformer, Command and Factory are common interfaces used
> as
> > > inner classes typically. These would not be accepted at Avalon, because
> > > they're not appropriate.
> >
> > We agree on this. They are generic patterns, and stand on their own
> > without a framework.
> >
> > > Identifiable, and new patterns such as Resetable, EmptyQueryable to be
> > > discussed are about what a _bean_ can support.
> >
> > Yes, also this is ok for me.
> > Resetable smells like lifecycle stuff really bad though ;-) while
> > EmptyQueryable, I dunno what it means. Maybe check if it's empty?
> > In this case I think it would be ok :-)
> >
> > BTW, I see these in lang, since any Object can be Identifiable, it
> > becomes something that is part of the language...
> >
> > > Avalon's interfaces are about Components. (Of course then there is the
> > > component vs bean discussion.)
> >
> > Not really.
> > It's about interfaces that relate to each other in a way that they need
> > to be supported by a framework or not.
> > In the first case, there are contracts between them that need an
> > external entity to validate the calls, so they are not for Commons.
> > It's easy enough to see that Command or Identifiable do not need such a
> > facility, and are *atomic* calls.
> > If they are part of a "transaction", then no.
> >
> > > So yes, Command may be a design pattern. But in terms of use, its a
> utility.
> > > Thats my distinction. Thats why I'm trying to separate these two pattern
> > > types (utility and bean). Because utility is ready to progress, and bean
> is
> > > not.
> >
> > Hmmm, I don't understand this...
> > Can you please explain it a bit more?
> >
> > > --
> > > Pattern charter so far:
> > > - No marker interfaces
> >
> > +1 (applies generally as a good design pattern itself, we could make
> > this part of the doco)
> >
> > > - No inversion of control interfaces (excludes Avalon
> > > Serviceable/Loggable...)
> >
> > +1
> >
> > > - No interfaces requiring non-Java objects as parameters (excludes
> Avalons
> > > Contextualizable/Parameterizable
> >
> > ? Contextualizable/Parameterizable is part of inversion of control too.
> >
> > > - No Component interfaces (excludes Avalons Startable/Suspendable...)
> >
> > Let's call them lifecycle.
> >
> > > - Probably no interfaces with more than two methods in it
> >
> > This can be a good indicator. Not a rule maybe, but a good indicator.
> >
> > Seems good so far.
> >
> > --
> > Nicola Ken Barozzi nicolaken@apache.org
> > - verba volant, scripta manent -
> > (discussions get forgotten, just code remains)
> > ---------------------------------------------------------------------
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [pattern] Pattern charter, whats in, whats out
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Well I don't want to be flamed, but...
- configuration/parameters, but not the IoC interface, should be in commons
[new project]
- logger, but not the IoC interface, is in commons [logging]
- component/service lookup, but not the IoC interface, could be be in
commons ([discovery] ??) but are probably more appropriate in Avalon
- activity, could be in commons [pattern]
- Enums/Exceptions, are in commons [lang]
- convertors (couldn't find it on website), should be implementation of
Transformer interface
To make these changes would be controversial in commons, and may require
incompatabilities in Avalon. Hardly desirable.
Two of the above are interesting - configuration and activity. I have code
for configuration available which I would love to see in a new commons
project. But its a matter of time..
Activity is just a set of convenient interfaces. The scary part for some
commons people is the belief that they _must_ be used in a framework, and
that they imply a certain ordering, that they can't be used independently
just on any old bean. This isn't my opinion, but I have no sense that
lifecycle methods will arrive in commons anytime soon.
Stephen
PS: I've signed up to Avalon, but if the traffic is too high then I may have
to stop
----- Original Message -----
From: "Nicola Ken Barozzi" <ni...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Saturday, August 10, 2002 7:40 PM
Subject: Re: [pattern] Pattern charter, whats in, whats out
> BTW, Stephen, sorry if I've been a bit too harsh in the last mails.
> I think that many of the concepts things you are trying to do re in
> Avalon, so I really invite you over to our list and project, you could
> be a valid support :-)
>
> Besides, if you could help me out in resolving once and for all the
> right separation and mix between Avalon and Commons, it would be awesome.
> Hint: We have a CascadingException.
> Lang has NestableException.
> What to do about it?
>
> Also, we have a "converter" package in Excalubur that could go in
> Commons maybe, as an implementation of the Transformer pattern.
> Take a look at it, and let me know.
>
> Now for your reply :-)
>
>
> Stephen Colebourne wrote:
> > From: "Nicola Ken Barozzi" <ni...@apache.org>
> >
> >> pattern==design patterns
> >> pattern!=just common interfaces
> >
> >
> > Predicate, Transformer, Command and Factory are common interfaces used
as
> > inner classes typically. These would not be accepted at Avalon, because
> > they're not appropriate.
>
> We agree on this. They are generic patterns, and stand on their own
> without a framework.
>
> > Identifiable, and new patterns such as Resetable, EmptyQueryable to be
> > discussed are about what a _bean_ can support.
>
> Yes, also this is ok for me.
> Resetable smells like lifecycle stuff really bad though ;-) while
> EmptyQueryable, I dunno what it means. Maybe check if it's empty?
> In this case I think it would be ok :-)
>
> BTW, I see these in lang, since any Object can be Identifiable, it
> becomes something that is part of the language...
>
> > Avalon's interfaces are about Components. (Of course then there is the
> > component vs bean discussion.)
>
> Not really.
> It's about interfaces that relate to each other in a way that they need
> to be supported by a framework or not.
> In the first case, there are contracts between them that need an
> external entity to validate the calls, so they are not for Commons.
> It's easy enough to see that Command or Identifiable do not need such a
> facility, and are *atomic* calls.
> If they are part of a "transaction", then no.
>
> > So yes, Command may be a design pattern. But in terms of use, its a
utility.
> > Thats my distinction. Thats why I'm trying to separate these two pattern
> > types (utility and bean). Because utility is ready to progress, and bean
is
> > not.
>
> Hmmm, I don't understand this...
> Can you please explain it a bit more?
>
> > --
> > Pattern charter so far:
> > - No marker interfaces
>
> +1 (applies generally as a good design pattern itself, we could make
> this part of the doco)
>
> > - No inversion of control interfaces (excludes Avalon
> > Serviceable/Loggable...)
>
> +1
>
> > - No interfaces requiring non-Java objects as parameters (excludes
Avalons
> > Contextualizable/Parameterizable
>
> ? Contextualizable/Parameterizable is part of inversion of control too.
>
> > - No Component interfaces (excludes Avalons Startable/Suspendable...)
>
> Let's call them lifecycle.
>
> > - Probably no interfaces with more than two methods in it
>
> This can be a good indicator. Not a rule maybe, but a good indicator.
>
> Seems good so far.
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [pattern] Pattern charter, whats in, whats out
Posted by Nicola Ken Barozzi <ni...@apache.org>.
BTW, Stephen, sorry if I've been a bit too harsh in the last mails.
I think that many of the concepts things you are trying to do re in
Avalon, so I really invite you over to our list and project, you could
be a valid support :-)
Besides, if you could help me out in resolving once and for all the
right separation and mix between Avalon and Commons, it would be awesome.
Hint: We have a CascadingException.
Lang has NestableException.
What to do about it?
Also, we have a "converter" package in Excalubur that could go in
Commons maybe, as an implementation of the Transformer pattern.
Take a look at it, and let me know.
Now for your reply :-)
Stephen Colebourne wrote:
> From: "Nicola Ken Barozzi" <ni...@apache.org>
>
>> pattern==design patterns
>> pattern!=just common interfaces
>
>
> Predicate, Transformer, Command and Factory are common interfaces used as
> inner classes typically. These would not be accepted at Avalon, because
> they're not appropriate.
We agree on this. They are generic patterns, and stand on their own
without a framework.
> Identifiable, and new patterns such as Resetable, EmptyQueryable to be
> discussed are about what a _bean_ can support.
Yes, also this is ok for me.
Resetable smells like lifecycle stuff really bad though ;-) while
EmptyQueryable, I dunno what it means. Maybe check if it's empty?
In this case I think it would be ok :-)
BTW, I see these in lang, since any Object can be Identifiable, it
becomes something that is part of the language...
> Avalon's interfaces are about Components. (Of course then there is the
> component vs bean discussion.)
Not really.
It's about interfaces that relate to each other in a way that they need
to be supported by a framework or not.
In the first case, there are contracts between them that need an
external entity to validate the calls, so they are not for Commons.
It's easy enough to see that Command or Identifiable do not need such a
facility, and are *atomic* calls.
If they are part of a "transaction", then no.
> So yes, Command may be a design pattern. But in terms of use, its a utility.
> Thats my distinction. Thats why I'm trying to separate these two pattern
> types (utility and bean). Because utility is ready to progress, and bean is
> not.
Hmmm, I don't understand this...
Can you please explain it a bit more?
> --
> Pattern charter so far:
> - No marker interfaces
+1 (applies generally as a good design pattern itself, we could make
this part of the doco)
> - No inversion of control interfaces (excludes Avalon
> Serviceable/Loggable...)
+1
> - No interfaces requiring non-Java objects as parameters (excludes Avalons
> Contextualizable/Parameterizable
? Contextualizable/Parameterizable is part of inversion of control too.
> - No Component interfaces (excludes Avalons Startable/Suspendable...)
Let's call them lifecycle.
> - Probably no interfaces with more than two methods in it
This can be a good indicator. Not a rule maybe, but a good indicator.
Seems good so far.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [pattern] Pattern charter, whats in, whats out
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Nicola Ken Barozzi" <ni...@apache.org>
> pattern==design patterns
> pattern!=just common interfaces
Predicate, Transformer, Command and Factory are common interfaces used as
inner classes typically. These would not be accepted at Avalon, because
they're not appropriate.
Identifiable, and new patterns such as Resetable, EmptyQueryable to be
discussed are about what a _bean_ can support.
Avalon's interfaces are about Components. (Of course then there is the
component vs bean discussion.)
So yes, Command may be a design pattern. But in terms of use, its a utility.
Thats my distinction. Thats why I'm trying to separate these two pattern
types (utility and bean). Because utility is ready to progress, and bean is
not.
--
Pattern charter so far:
- No marker interfaces
- No inversion of control interfaces (excludes Avalon
Serviceable/Loggable...)
- No interfaces requiring non-Java objects as parameters (excludes Avalons
Contextualizable/Parameterizable
- No Component interfaces (excludes Avalons Startable/Suspendable...)
- Probably no interfaces with more than two methods in it
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [pattern] Pattern charter, whats in, whats out
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen Colebourne wrote:
> From: "Nicola Ken Barozzi" <ni...@apache.org>
>
>>In fact we have decided out of experience that marker interfaces "are
>>bad (TM)", and so we have also decided to deprecate the marker Component
>>interface.
>
>
> This is where I am at with Immutable. This will disppear from [pattern] real
> soon now.
>
>
>>>>Group 3 -Bean style patterns:
>>>>- Identifiable, (also Resetable, Destroyable, Initializable,
>>>>StateChangeable, EmptyQueryable, Saveable, Loadable, ...
>>>
>>>That seems avalon-like to me.
>>
>>All these are 100% Avalon, and you would get a lightning fast -1000 from
>>me. We already have many of these interfaces, and they were discussed
>>more than 99% of programmers could tollerate ;-) .
>
>
> Thats really what this thread is about - Pattern charter. Defining exactly
> which to include ans which to exclude.
>
>
>>>>My preference is thus as follows:
>>>>Group 1 becomes part of [lang]
>>>
>>>I think collections may be a better place, if they need it.
>>>[lang] is great as long as it defines utils - if it gets into marker
>>>interface business, then we have a problem.
>>
>>Collections?
>>Gee, wierd.
>>Lang is about Utils... and util?
>>
>>I would keep them in pattern, since they are to use Patterns.
>>Or are you two mixing 3 with 1?
>
>
> Somehow, group 3 and group 1 must be separated. My solution is move group 1
> to [lang]. They are basic utility interfaces, thats just where they should
> be.
>
>
>>>>Group 3 becomes [pattern], in the sandbox, not depended on, not in the
>>>>upcoming core.jar
>>>
>>AAAAgghhhhhh >:-O
>>
>>-1000000000000
>>
>>You want to put Avalon in commons!
>
>
> No. If Avalon has all of these, then great. [pattern] ceases to exist.
No, pattern==design patterns.
Gang of Four types for example.
> But
> there may yet be some patterns that are non-lifecycle and non-utility that
> don't fit in either camp.
Identifiable
we already discussed this one, I'm +1 for it
Resetable
this I'm not sure...
Destroyable, Initializable,
-1 it's about lifecycle
StateChangeable, EmptyQueryable, Saveable, Loadable
Still unsure about these, will need to discuss them as we
did with Identifiable, the discussion was very profitable
But still, I'm confused... I think that what you want to put in pattern
is more about lang, and viceversa. How come?
As I said
pattern==design patterns
pattern!=just common interfaces
Simple rule of the thumb: if there is a pubblication about it on the net
that calls it a design-pattern, and it's not related to lifecycle or to
a framework, it goes in pattern.
Seems easy enough to me...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [pattern] Pattern charter, whats in, whats out
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Nicola Ken Barozzi" <ni...@apache.org>
> In fact we have decided out of experience that marker interfaces "are
> bad (TM)", and so we have also decided to deprecate the marker Component
> interface.
This is where I am at with Immutable. This will disppear from [pattern] real
soon now.
> >>Group 3 -Bean style patterns:
> >>- Identifiable, (also Resetable, Destroyable, Initializable,
> >>StateChangeable, EmptyQueryable, Saveable, Loadable, ...
> >
> > That seems avalon-like to me.
>
> All these are 100% Avalon, and you would get a lightning fast -1000 from
> me. We already have many of these interfaces, and they were discussed
> more than 99% of programmers could tollerate ;-) .
Thats really what this thread is about - Pattern charter. Defining exactly
which to include ans which to exclude.
> >>My preference is thus as follows:
> >>Group 1 becomes part of [lang]
> >
> > I think collections may be a better place, if they need it.
> > [lang] is great as long as it defines utils - if it gets into marker
> > interface business, then we have a problem.
>
> Collections?
> Gee, wierd.
> Lang is about Utils... and util?
>
> I would keep them in pattern, since they are to use Patterns.
> Or are you two mixing 3 with 1?
Somehow, group 3 and group 1 must be separated. My solution is move group 1
to [lang]. They are basic utility interfaces, thats just where they should
be.
> >>Group 3 becomes [pattern], in the sandbox, not depended on, not in the
> >>upcoming core.jar
>
> AAAAgghhhhhh >:-O
>
> -1000000000000
>
> You want to put Avalon in commons!
No. If Avalon has all of these, then great. [pattern] ceases to exist. But
there may yet be some patterns that are non-lifecycle and non-utility that
don't fit in either camp.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [pattern] Pattern charter, whats in, whats out
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Costin Manolache wrote:
> Stephen Colebourne wrote:
>
>
>>Ola asked on what criteria I would accept or reject patterns. Other
>>discussions have focussed on merging with [lang] or whether patterns are
>>appropriate for commons. So I thought I'd look into what has been coded so
>>far:
>>
>>There are already groups appearing in [pattern]:
>>
>>Group 1 - Utility patterns, like java.util.Comparator:
>>- Predicate, Command, Transformer, Factory, (ThrowableHandler)
>>They are intended to be implemented by an inner class, not a bean (what I
>>mean is that the implementing class will only implement this one method).
>>Thus they represent utility bits of code. These are already in commons
>>(collections) and Predicate will probably be used by IO
>
>
> As long as they are clearly needed and used in the context of an
> specific utility - it's fine. If Collections define a Predicate
> that will be used to operate on the collection data - it's a perfect
> use of an interface, and people using collections can use that
> interface when they need to.
>
> +1 on this - as long as the collection package actually needs them.
Exactly :-) +1
>>Group 2 - Marker interface patterns:
>>- Immutable, (also Null, Mutable, Bean ...)
>>These marker interfaces rely on something (ie. a framework) knowing about
>>them. For Immutable, I included ImmutableUtils to try to be a basic
>>framework. But it doesn't really work. The problem is that there is no
>>clear use case.
>
>
> I would sugest moving those to avalon. They also have a number of marker
> interfaces, and there is little use of checking if Immutable is implemented
> if some components don't use the interface. In other words they make
> sense inside a framework ( like avalon ) when all components are expected
> to use them, they don't make sense on commons.
I agree. +1 (if-when Avalon accepts them)
In fact we have decided out of experience that marker interfaces "are
bad (TM)", and so we have also decided to deprecate the marker Component
interface.
This is meta-information, and is now specified in descriptors about the
lifestyle of a Component/Service.
>>Group 3 -Bean style patterns:
>>- Identifiable, (also Resetable, Destroyable, Initializable,
>>StateChangeable, EmptyQueryable, Saveable, Loadable, ... the list could be
>>long, and you'll have to guess what some of these are about)
>>Unlike group 1, these are intended to be implemented by a bean, not an
>>inner class (what I mean is a proper class - one with a number of methods
>>other than those of the pattern interface). They allow that bean to
>>perform certain common behaviours in a standardised way.
>
>
> That seems avalon-like to me.
>
> They have components implementing specific interfaces - Identifiable
> would be a perfect fit ( if they don't already have it ) :-)
> Destroyable/Initializable is lifecycle ( you'll probably need to fight
> some wars to get them to change their lifecycle ).
All these are 100% Avalon, and you would get a lightning fast -1000 from
me. We already have many of these interfaces, and they were discussed
more than 99% of programmers could tollerate ;-) .
I would suggest you to join us over at Avalon, you seem to like it :-)
>>My preference is thus as follows:
>>Group 1 becomes part of [lang]
>
> I think collections may be a better place, if they need it.
> [lang] is great as long as it defines utils - if it gets into marker
> interface business, then we have a problem.
Collections?
Gee, wierd.
Lang is about Utils... and util?
I would keep them in pattern, since they are to use Patterns.
Or are you two mixing 3 with 1?
>>Group 2 dies, unless Avalon is interested
>
>
> I'm not an expert in avalon (:-), but they seem to fit - I know they
> have quite a few similar interfaces.
We already do in fact.
Propose them over there.
>>Group 3 becomes [pattern], in the sandbox, not depended on, not in the
>>upcoming core.jar
AAAAgghhhhhh >:-O
-1000000000000
You want to put Avalon in commons!
> My criteria for getting it into commons-proper: if it's a tool/utility
> that can be _used_ by a project, and if there is a chance that jakarta
> projects will adopt it - it's fine.
I'd say let's keep pattern a package for interfaces-classes that help
implement design patterns.
Marker interfaces, forget them.
Lifecycle, don't you dare >;-P
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [pattern] Pattern charter, whats in, whats out
Posted by Costin Manolache <cm...@yahoo.com>.
Stephen Colebourne wrote:
> Ola asked on what criteria I would accept or reject patterns. Other
> discussions have focussed on merging with [lang] or whether patterns are
> appropriate for commons. So I thought I'd look into what has been coded so
> far:
>
> There are already groups appearing in [pattern]:
>
> Group 1 - Utility patterns, like java.util.Comparator:
> - Predicate, Command, Transformer, Factory, (ThrowableHandler)
> They are intended to be implemented by an inner class, not a bean (what I
> mean is that the implementing class will only implement this one method).
> Thus they represent utility bits of code. These are already in commons
> (collections) and Predicate will probably be used by IO
As long as they are clearly needed and used in the context of an
specific utility - it's fine. If Collections define a Predicate
that will be used to operate on the collection data - it's a perfect
use of an interface, and people using collections can use that
interface when they need to.
+1 on this - as long as the collection package actually needs them.
> Group 2 - Marker interface patterns:
> - Immutable, (also Null, Mutable, Bean ...)
> These marker interfaces rely on something (ie. a framework) knowing about
> them. For Immutable, I included ImmutableUtils to try to be a basic
> framework. But it doesn't really work. The problem is that there is no
> clear use case.
I would sugest moving those to avalon. They also have a number of marker
interfaces, and there is little use of checking if Immutable is implemented
if some components don't use the interface. In other words they make
sense inside a framework ( like avalon ) when all components are expected
to use them, they don't make sense on commons.
> Group 3 -Bean style patterns:
> - Identifiable, (also Resetable, Destroyable, Initializable,
> StateChangeable, EmptyQueryable, Saveable, Loadable, ... the list could be
> long, and you'll have to guess what some of these are about)
> Unlike group 1, these are intended to be implemented by a bean, not an
> inner class (what I mean is a proper class - one with a number of methods
> other than those of the pattern interface). They allow that bean to
> perform certain common behaviours in a standardised way.
That seems avalon-like to me.
They have components implementing specific interfaces - Identifiable
would be a perfect fit ( if they don't already have it ) :-)
Destroyable/Initializable is lifecycle ( you'll probably need to fight
some wars to get them to change their lifecycle ).
> My preference is thus as follows:
> Group 1 becomes part of [lang]
I think collections may be a better place, if they need it.
[lang] is great as long as it defines utils - if it gets into marker
interface business, then we have a problem.
> Group 2 dies, unless Avalon is interested
I'm not an expert in avalon (:-), but they seem to fit - I know they
have quite a few similar interfaces.
> Group 3 becomes [pattern], in the sandbox, not depended on, not in the
> upcoming core.jar
My criteria for getting it into commons-proper: if it's a tool/utility
that can be _used_ by a project, and if there is a chance that jakarta
projects will adopt it - it's fine.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>