commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: [COLLECTIONS] 3.3 release
Date Thu, 07 May 2009 05:17:09 GMT

On May 5, 2009, at 11:15 PM, Jörg Schaible wrote:

> James Carman wrote at Mittwoch, 6. Mai 2009 03:12:
>
>> On Tue, May 5, 2009 at 6:36 PM, Matt Benson <gudnabrsam@yahoo.com>  
>> wrote:
>>>
>>> I feel differently--how many times do we need to duplicate code  
>>> that does
>>> the same damned thing amongst the various components?  For  
>>> example, we've
>>> now added MethodUtils to [lang], but [collections] has its own set  
>>> of
>>> code supporting InvokerTransformer.  [functor] doesn't have an  
>>> analogous
>>> function because it seemed to me silly to keep rewriting and/or  
>>> copying
>>> the necessary code.  IMHO we of the Commons need to establish an  
>>> approach
>>> for "mixin" components, optional dependencies, svn externals,  
>>> something,
>>> to avoid doing this again and again and again.
>>
>> I'm with Matt on this one.  I really hate that Collections has its  
>> own
>> functors and I really hate having to copy code from one place to
>> another all the time.
>>
>> I'd like to be able to keep my own little library of nifty functors
>> and use those throughout my application in different contexts.  Right
>> now, I have to use adapters all the time to go between one or the
>> other (functors vs. collections).  Yuck!  I've even gone as far as
>> creating little frameworky type classes that take these functor
>> classes (TransformerListCellRenderer and TransformerTreeCellRenderer
>> come to mind).
>>
>> Perhaps we could split functors into an API jar and a utils or
>> algorithms jar?  The API would have all the main interfaces in it  
>> (the
>> stuff in org.apache.commons.functor).  Collections could depend on  
>> the
>> API and if folks want to use stuff from functor to do what they want,
>> then so be it.  If not, oh well.  The API itself really can't evolve
>> that much.  Those interfaces have been the same for a long time  
>> (other
>> than the generics)
>
> Maybe it's also time to think about more fine grained artifacts.  
> With Maven
> the dependency management is no longer that worse. We could have
>
>  collections-x.y.jar
>  collections-functor-x.y.jar
>
> with the latter providing the stuff of collections depending on  
> functor.
> This will not work for all kind dependencies between the commons stuff
> (e.g. helper classes from commons-io), but there are some components  
> now,
> where an currently optional dep simply means additional  
> functionality (e.g.
> in configuration or vfs).
>
> Opinions?
>

Well, it should be obvious that this seeming aversion to dependencies  
isn't something I consider part of a good design. I've added several  
to both configuration and vfs, all of which - as you pointed out - are  
optional. I really don't understand the benefit of having mulitple  
copies of code in various projects that will eventually get out of  
synch vs just sharing one copy. I thought that was what commons was  
supposed to be all about.

OTOH, commons components should be fairly small so the number of  
dependencies shouldn't get too out of hand.

Ralph


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


Mime
View raw message