Your argument makes perfect sense, except that [lang] also wants to be the lowest level, no dependency library. This is why functors are could reside in [lang], so this kind of cross dependency isn't an issue.
I agree that bean based functors would sit in [beanutils], and io based functors in [io]. The only [lang] possible functors I can think of was type conversion, but that could alternatively sit as a separate component in its own right. Stephen ----- Original Message ----- From: "Tom Drake" <[EMAIL PROTECTED]> > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
