commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [collections][lang] Functors, pre-vote
Date Fri, 13 Dec 2002 10:44:33 GMT
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" <Tom.Drake@tavant.com>
> 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:bayard@generationjava.com]
> 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:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message