commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cost...@covalent.net
Subject Re: [pattern] Pattern charter, whats in, whats out
Date Sun, 11 Aug 2002 15:05:29 GMT
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" <nicolaken@apache.org>
> To: "Jakarta Commons Developers List" <commons-dev@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" <nicolaken@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:
> <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>
> 
> 


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