commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Drake <>
Subject RE: [collections][lang] Functors, pre-vote
Date Thu, 12 Dec 2002 20:14:25 GMT
I think we agree on just about everything, excepting 
dependancies between [functor] and [lang].

I'm not very familiar with the scope of [lang] so take 
my comments with a grain of salt.

My point is that [functor] (defined as having no 
dependancies on any other apache project) represents
a set of concepts that are completely orthogonal to the
other packages. All other packages should be free to use
[functor] w/out having to worry about circular dependencies.

As long as [functor] is scoped with this minimalist view,
then this is easily achievable.

Implementations of [functor] interfaces that require [lang]
should be placed in [lang]. Implementations depending on [beanutils]
belong in [beanutils].

-----Original Message-----
From: Henri Yandell []
Sent: Thursday, December 12, 2002 11:55 AM
To: Jakarta Commons Developers List
Subject: RE: [collections][lang] Functors, pre-vote

On Thu, 12 Dec 2002, Tom Drake wrote:

> Has anyone considered that all functor implementations
> do not belong in [functor].

I actually don't see any reasons yet why all functor implementations don't
belong in functor [or the place where the interfaces/core impls are],
apart from release issues, in which case the implementation can just be
private in the other lib.

Any implementations of functor which are only dependent on functor should
be in functor.

An implementation such as in [io] now definitely belongs in [io] as it is
to do with FileFilters.

> If [functor] contains the functor interfaces, as well as
> selected dependency-free implementation and utility classes.

> Then, if [lang], [collections], or [foo] wants to use them they are free
> to, without worrying about dependency hell. If [lang] has a need
> to create a [lang]-specific Predicate or Transformer, then they
> should go right ahead and create it somewhere under [lang], introducing
> a dependancy on [functor].

Lang depending on functor should raise alarm bells. Let's take JDK as an

java.lang is pretty core right?

java.util is also pretty common. java.util obviously depends on java.lang.
Does java.lang depend in anyway on java.util??? I wouldn't rule the chance

So circular dependency.

Now look at Lang. It's do do with java.lang things. Everyone uses
java.lang things, so there's no package which could not have a desire to
be dependent on Lang.

Thus:  Functor dependent on Lang is a concept which must be protected.

Now, we're saying that Functor things are these really standard interfaces
that any code which matches the code signature will probably want to
consider having.

If Lang happens to have such things, then bang. That's our circular
dependency. So the hope is that something like Lang does not have a
dependency on Functor.

Collections doesn't care, it'll depend on both libraries. Same for IO and
other things out there.

[Equally, assuming it's okay for Commons Lang to use java.util.Vector etc,
why can't Commons Lang depend on Commons Collection? Except that I've
already declared that every library should protect the possibility of a
Lang dependency]

> By way of example, I submitted a BeanPropertyTransformer class
> (as part of a large submission) a week or so ago. This class
> implements Transformer, but uses PropertyUtils to transform the
> Object into a 'named' bean property. Such an implementation class
> probably doesn't belong in [collections] or [functor], but perhaps
> belongs with [beanutils]. However, adding it to [beanutils] creates
> a dependancy on [functor].

This isn't a functor implementation in my view. Maybe I'm belabouring a
point. It's a Bean implementation which fits the functor standard. The
same way that BeanComparator is in BeanUtils and not in Collections.

Your class should be in BeanUtils, and as Functor is a higher-priority
package in dependency terms [i need to define the concept of priority here
somehow] then BeanUtils should depend on Functor.

> So, I guess I'm saying that the charter for [functor] should
> stipulate that no external dependancies may be present. This being
> the case, everything that needs a functor interface, or one of it's basic
> implementation classes, it simply depends on [functor]. If it needs a
> functor implementation that exists in some other package (like [lang])
> then it must depend on that other package.

I claim that Functor should depend on Lang. In fact, Lang should not
depend on anything else ;)

> Such a stipulation guarantees, to some extent, that [functor] will
> always be fairly compact, since it may not contain any dependencies
> on any other org.apache package.

*nod* Except functor isn't unique in its specialness.


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

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

View raw message