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 [mailto:[EMAIL PROTECTED]] 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 example: 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 out. 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. Hen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
