You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Tom Drake <To...@tavant.com> on 2002/12/05 19:35:32 UTC

RE: [general] lang scope? (was Re: [collections][lang] Predicate etc impls, was Re: commons-collections: New code contribution.)

It sounds like I've jumped into a bit of a hornets nest.

I was thinking this morning that such a move will run a high risk of
creating a circular dependancy between [collections] and [lang][functor]. It
seems likely that functors would want to use collection objects and
vice-versa. If I'm right about this, then all this code really belongs under
the same package.



-----Original Message-----
From: Rodney Waldhoff [mailto:rwaldhoff@apache.org]
Sent: Thursday, December 05, 2002 9:47 AM
To: Jakarta Commons Developers List
Subject: [general] lang scope? (was Re: [collections][lang] Predicate
etc impls, was Re: commons-collections: New code contribution.)



On Thu, 5 Dec 2002 scolebourne@btopenworld.com wrote:

> The plan is to make [collections] depend on [lang] and deprecate the
> Predicate etc. interfaces in [collections].

At the risk of becoming increasingly unpopular with the lang folks, for
reasons similiar to those I enumerated in [1] (and others), I'm
uncomfortable with moving Predicate et al to lang.  I'm having a lot of
trouble seeing lang as meeting the "Each package must have a clearly
defined purpose, scope, and API -- Do one thing well, and keep your
contracts." criterion.

Don't get me wrong, I think all of this is great stuff, but why does it
all have to be in lang?  If it doesn't meet the common reuse principle, it
should be in a different component.  The current (i.e., released) contents
of o.a.c.lang, o.a.c.lang.builder, o.a.c.lang.enum and
o.a.c.lang.exception seem reasonably coherent, but I don't think the
either the functor or the reflection packages are a clean fit (with
respect to the CRP, R/REP, etc.), either with each other or the other
classes in lang.

[1]
<http://archives.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.a
pache.org&msgNo=19869>


--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [general] lang scope?

Posted by Henri Yandell <ba...@generationjava.com>.

On Thu, 5 Dec 2002, robert burrell donkin wrote:

> On Thursday, December 5, 2002, at 06:35 PM, Tom Drake wrote:
>
> > It sounds like I've jumped into a bit of a hornets nest.
>
> this is actually pretty tame :)

+1. We need to spice it up.

> i suppose that it's the implementations rather than the interfaces that
> will depend on collection objects.
>
> this might point towards having a separate (possibly revamped) pattern
> component. the interfaces might live in lang and the implementations in
> pattern. pattern could depend on collection whereas collection could
> depend on lang.

I'm over here in the corner making sick noises. The
maintanance/release-management of such a thing scares me.

Hen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [general] lang scope?

Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Thursday, December 5, 2002, at 06:35 PM, Tom Drake wrote:

> It sounds like I've jumped into a bit of a hornets nest.

this is actually pretty tame :)

but it's too late to jump of the frying pan...

> I was thinking this morning that such a move will run a high risk of
> creating a circular dependancy between [collections] and [lang][functor]. 
> It
> seems likely that functors would want to use collection objects and
> vice-versa. If I'm right about this, then all this code really belongs 
> under
> the same package.

(i don't have a deep understanding of the issues so this might be 
completely left field.)

i suppose that it's the implementations rather than the interfaces that 
will depend on collection objects.

this might point towards having a separate (possibly revamped) pattern 
component. the interfaces might live in lang and the implementations in 
pattern. pattern could depend on collection whereas collection could 
depend on lang.

- robert

> -----Original Message-----
> From: Rodney Waldhoff [mailto:rwaldhoff@apache.org]
> Sent: Thursday, December 05, 2002 9:47 AM
> To: Jakarta Commons Developers List
> Subject: [general] lang scope? (was Re: [collections][lang] Predicate
> etc impls, was Re: commons-collections: New code contribution.)
>
>
>
> On Thu, 5 Dec 2002 scolebourne@btopenworld.com wrote:
>
>> The plan is to make [collections] depend on [lang] and deprecate the
>> Predicate etc. interfaces in [collections].
>
> At the risk of becoming increasingly unpopular with the lang folks, for
> reasons similiar to those I enumerated in [1] (and others), I'm
> uncomfortable with moving Predicate et al to lang.  I'm having a lot of
> trouble seeing lang as meeting the "Each package must have a clearly
> defined purpose, scope, and API -- Do one thing well, and keep your
> contracts." criterion.
>
> Don't get me wrong, I think all of this is great stuff, but why does it
> all have to be in lang?  If it doesn't meet the common reuse principle, it
> should be in a different component.  The current (i.e., released) contents
> of o.a.c.lang, o.a.c.lang.builder, o.a.c.lang.enum and
> o.a.c.lang.exception seem reasonably coherent, but I don't think the
> either the functor or the reflection packages are a clean fit (with
> respect to the CRP, R/REP, etc.), either with each other or the other
> classes in lang.
>
> [1]
> <http://archives.apache.org/eyebrowse/ReadMsg?listName=commons-
> dev@jakarta.a
> pache.org&msgNo=19869>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>