> 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 am in favor of functors belonging in lang, _but_ if that makes [collection] and others reluctant to use the functors, I realize that they have to be in a package/component for themselves. > 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. Maybe that is the only way to go. In such cases we have to state for both [functor] and [lang] that they may not have any dependencies. [This increases the need for a bundled distribution of at least what can be considered a [core] component (classes needed or useful in almost any context, be it Swing, servlets, EJBs, comman-line apps).] /O > ----- 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
