commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodney Waldhoff <>
Subject Re: [VOTE][PROPOSAL] commons-functor
Date Mon, 30 Dec 2002 23:42:50 GMT
On Thu, 19 Dec 2002, Costin Manolache wrote:

> If this means another round of "where should this class be located" and
> dependency nightmares: I'm -1 ( it is a majority vote and probably that
> won't change the result, but I want to express my frustration somehow ).

This is meant as a resolution to round of "where should this class be
located" discussions, and seems or at least seemed to represent an
informal consesnsus on the issue (cf

> It seems one of the reasons for this proposal is that both collections
> and lang have something like that and can't agree on a dependency.
> A better solution would be to have a majority vote ( or flip
> a coin ) to decide which of the 2 should have functor, and live with the
> result.

Those aren't my reasons.

For me, the primary reasons for this proposal are:

(1) a functor-related component forms a cohesive, atomic unit that meets
both the hard and soft criteria for a commons component--it has a clearly
defined purpose and scope, it does one thing, and hopefully will do it
well.  The functor types are likely to be used, changed and released
together, and to be mutually dependent. (The same statements are not true
for either functor-in-lang or functor-in-collections.)

(2) there is some demand for a functor-related component, as witnessed by
the similar code in collections and lang (and it's easy to find instances
of functor-related interfaces throughout commons and for that matter
jakarta), and the sometimes lively debate on this issue.

> Or just pick a neutral interface and have both implement the interface.

Well yes, that's one approach. Arguably, that's this approach. But absent
functor, where does that interface live?

> Or even better - pick a design pattern ( a method name and signature )

I suspect there is a reason no one has developed the "design patterns
framework", or for that matter, why design patterns are generally
expressed as prose rather than code.

> and use reflection to wrap any class that implement the pattern.

A reflection-based implementation (for instance, something like
MethodPredicate(Object,Method)) seems appropriate in some circumstances
(indeed I've had something like that in mind for a little while), but
again, absent functor, where should that functionality live?

For an extended analysis of this situtation, see my next post.

 - R.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message