[lang][collections] Overlap; Collections thoughts

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[lang][collections] Overlap; Collections thoughts

Henri Yandell
Overlap between Lang and Collections is starting to increase a bit.
Requested items for ArrayUtils (LANG-238, LANG-470) are better
implemented imo as an ArraySet class. An easy add to Collections.

ComparableComparator made its way (privately) over for the new Range
class. Fair enough - Comparable and Comparator also overlap between
lang.* and util.*.

I have a JIRA issue threat to consider moving Collections code over to
Lang if Collections becomes dead [LANG-532]  :)

---

One thought I have for Collections is splitting it up into two parts.
The first would be items that add to collections in the JDK, the
second would be additional collections. The former could conceivably
merge with Lang, the latter could also be split up into an SPI style
approach with an API jar and an Impl jar. The latter would most likely
depend on the former.

It would then be tempting to also merge Functors for example into the
latter, plus I think we could get back on the bandwagon of adding new
things, like the long standing Trie JIRA issue.

Biased note: Part of this is that I'm interested in the JDK enhancing
parts, but not all the implementations of weird and whacky
collections; however I think this is likely not just me and that the
separation would do wonders for the release cycle.

Thoughts?

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] Overlap; Collections thoughts

Henri Yandell
Additional thought... the Collections Test library should move to
being a first class component in Commons rather than a side thought
inside Collections. So this is three new components from one:

* Test library
* Core JDK [Lang merge?]
* Collections impls

On Wed, Dec 30, 2009 at 2:18 AM, Henri Yandell <[hidden email]> wrote:

> Overlap between Lang and Collections is starting to increase a bit.
> Requested items for ArrayUtils (LANG-238, LANG-470) are better
> implemented imo as an ArraySet class. An easy add to Collections.
>
> ComparableComparator made its way (privately) over for the new Range
> class. Fair enough - Comparable and Comparator also overlap between
> lang.* and util.*.
>
> I have a JIRA issue threat to consider moving Collections code over to
> Lang if Collections becomes dead [LANG-532]  :)
>
> ---
>
> One thought I have for Collections is splitting it up into two parts.
> The first would be items that add to collections in the JDK, the
> second would be additional collections. The former could conceivably
> merge with Lang, the latter could also be split up into an SPI style
> approach with an API jar and an Impl jar. The latter would most likely
> depend on the former.
>
> It would then be tempting to also merge Functors for example into the
> latter, plus I think we could get back on the bandwagon of adding new
> things, like the long standing Trie JIRA issue.
>
> Biased note: Part of this is that I'm interested in the JDK enhancing
> parts, but not all the implementations of weird and whacky
> collections; however I think this is likely not just me and that the
> separation would do wonders for the release cycle.
>
> Thoughts?
>
> Hen
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] Overlap; Collections thoughts

Benson Margulies
In reply to this post by Henri Yandell
Henri,

To make this more interesting, the new collections over in mahout-math
might be covering some of the territory you are looking for here.

--benson


On Wed, Dec 30, 2009 at 5:18 AM, Henri Yandell <[hidden email]> wrote:

> Overlap between Lang and Collections is starting to increase a bit.
> Requested items for ArrayUtils (LANG-238, LANG-470) are better
> implemented imo as an ArraySet class. An easy add to Collections.
>
> ComparableComparator made its way (privately) over for the new Range
> class. Fair enough - Comparable and Comparator also overlap between
> lang.* and util.*.
>
> I have a JIRA issue threat to consider moving Collections code over to
> Lang if Collections becomes dead [LANG-532]  :)
>
> ---
>
> One thought I have for Collections is splitting it up into two parts.
> The first would be items that add to collections in the JDK, the
> second would be additional collections. The former could conceivably
> merge with Lang, the latter could also be split up into an SPI style
> approach with an API jar and an Impl jar. The latter would most likely
> depend on the former.
>
> It would then be tempting to also merge Functors for example into the
> latter, plus I think we could get back on the bandwagon of adding new
> things, like the long standing Trie JIRA issue.
>
> Biased note: Part of this is that I'm interested in the JDK enhancing
> parts, but not all the implementations of weird and whacky
> collections; however I think this is likely not just me and that the
> separation would do wonders for the release cycle.
>
> Thoughts?
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] Overlap; Collections thoughts

Henri Yandell
Briefly looking at
http://svn.apache.org/repos/asf/lucene/mahout/trunk/math/src/main/java/org/apache/mahout/math/
- it looks like this is more along the lines of the Collections as new
data structures/algorithms rather than Collections as JDK enhancer?

Ignoring the edge case overlaps with Math and Lang anyway.

Hen

On Wed, Dec 30, 2009 at 3:58 AM, Benson Margulies <[hidden email]> wrote:

> Henri,
>
> To make this more interesting, the new collections over in mahout-math
> might be covering some of the territory you are looking for here.
>
> --benson
>
>
> On Wed, Dec 30, 2009 at 5:18 AM, Henri Yandell <[hidden email]> wrote:
>> Overlap between Lang and Collections is starting to increase a bit.
>> Requested items for ArrayUtils (LANG-238, LANG-470) are better
>> implemented imo as an ArraySet class. An easy add to Collections.
>>
>> ComparableComparator made its way (privately) over for the new Range
>> class. Fair enough - Comparable and Comparator also overlap between
>> lang.* and util.*.
>>
>> I have a JIRA issue threat to consider moving Collections code over to
>> Lang if Collections becomes dead [LANG-532]  :)
>>
>> ---
>>
>> One thought I have for Collections is splitting it up into two parts.
>> The first would be items that add to collections in the JDK, the
>> second would be additional collections. The former could conceivably
>> merge with Lang, the latter could also be split up into an SPI style
>> approach with an API jar and an Impl jar. The latter would most likely
>> depend on the former.
>>
>> It would then be tempting to also merge Functors for example into the
>> latter, plus I think we could get back on the bandwagon of adding new
>> things, like the long standing Trie JIRA issue.
>>
>> Biased note: Part of this is that I'm interested in the JDK enhancing
>> parts, but not all the implementations of weird and whacky
>> collections; however I think this is likely not just me and that the
>> separation would do wonders for the release cycle.
>>
>> Thoughts?
>>
>> Hen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] Overlap; Collections thoughts

Benson Margulies
If by 'jdk enhancer' you mean 'provide newer functionality to older
jdks', I completely agree.

On Sat, Jan 2, 2010 at 3:31 AM, Henri Yandell <[hidden email]> wrote:

> Briefly looking at
> http://svn.apache.org/repos/asf/lucene/mahout/trunk/math/src/main/java/org/apache/mahout/math/
> - it looks like this is more along the lines of the Collections as new
> data structures/algorithms rather than Collections as JDK enhancer?
>
> Ignoring the edge case overlaps with Math and Lang anyway.
>
> Hen
>
> On Wed, Dec 30, 2009 at 3:58 AM, Benson Margulies <[hidden email]> wrote:
>> Henri,
>>
>> To make this more interesting, the new collections over in mahout-math
>> might be covering some of the territory you are looking for here.
>>
>> --benson
>>
>>
>> On Wed, Dec 30, 2009 at 5:18 AM, Henri Yandell <[hidden email]> wrote:
>>> Overlap between Lang and Collections is starting to increase a bit.
>>> Requested items for ArrayUtils (LANG-238, LANG-470) are better
>>> implemented imo as an ArraySet class. An easy add to Collections.
>>>
>>> ComparableComparator made its way (privately) over for the new Range
>>> class. Fair enough - Comparable and Comparator also overlap between
>>> lang.* and util.*.
>>>
>>> I have a JIRA issue threat to consider moving Collections code over to
>>> Lang if Collections becomes dead [LANG-532]  :)
>>>
>>> ---
>>>
>>> One thought I have for Collections is splitting it up into two parts.
>>> The first would be items that add to collections in the JDK, the
>>> second would be additional collections. The former could conceivably
>>> merge with Lang, the latter could also be split up into an SPI style
>>> approach with an API jar and an Impl jar. The latter would most likely
>>> depend on the former.
>>>
>>> It would then be tempting to also merge Functors for example into the
>>> latter, plus I think we could get back on the bandwagon of adding new
>>> things, like the long standing Trie JIRA issue.
>>>
>>> Biased note: Part of this is that I'm interested in the JDK enhancing
>>> parts, but not all the implementations of weird and whacky
>>> collections; however I think this is likely not just me and that the
>>> separation would do wonders for the release cycle.
>>>
>>> Thoughts?
>>>
>>> Hen
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] Overlap; Collections thoughts

Phil Steitz
In reply to this post by Henri Yandell
Henri Yandell wrote:

> Overlap between Lang and Collections is starting to increase a bit.
> Requested items for ArrayUtils (LANG-238, LANG-470) are better
> implemented imo as an ArraySet class. An easy add to Collections.
>
> ComparableComparator made its way (privately) over for the new Range
> class. Fair enough - Comparable and Comparator also overlap between
> lang.* and util.*.
>
> I have a JIRA issue threat to consider moving Collections code over to
> Lang if Collections becomes dead [LANG-532]  :)
>
> ---
>
> One thought I have for Collections is splitting it up into two parts.
> The first would be items that add to collections in the JDK, the
> second would be additional collections. The former could conceivably
> merge with Lang, the latter could also be split up into an SPI style
> approach with an API jar and an Impl jar. The latter would most likely
> depend on the former.
>
> It would then be tempting to also merge Functors for example into the
> latter, plus I think we could get back on the bandwagon of adding new
> things, like the long standing Trie JIRA issue.
>
> Biased note: Part of this is that I'm interested in the JDK enhancing
> parts, but not all the implementations of weird and whacky
> collections; however I think this is likely not just me and that the
> separation would do wonders for the release cycle.

Interesting idea and forces us to really think about the scopes of
both [lang] and [collections].  Both started as really extensions of
the JDK and both have had large parts obsoleted by advances in the
JDK.  I guess it still makes sense to consider [lang] as simple
extensions of the JDK and [collections] as data structures.  What I
have a little trouble with is where to draw the line within
[collections].  I think functors is a bad example, as one could
argue that this belongs in neither [collections] nor [lang] - oh
wait, we did that and created [functors] (lets not divert down that
rabbit hole ;).  Better examples of what might be peeled off into
[lang] could be the iterators or decorators.  Can you get a little
more specific on what parts of [collections] you see as in scope for
 merging into [lang]?

I am +1 on publishing the collections test jar as a separate maven
artifact.  We don't have to create a separate subproject for that, IMO.

Note that lots of other commons components - [math], [net],
[functors], [configuration], [beanutils] all come to mind
immediately - have elements that amount to extensions of the JDK.
Like [collections], they all have a more specialized domain that is
their primary focus.  So the natural question is, if this makes
sense for [collections], why not everywhere else?  Answering that
question might help clarify intent here.

One final comment is that a logical alternative is to just split
[collections] internally into multiple pieces with separate release
cycles. Managing dependencies among the subcomponents and user
documentation might be tricky.  IIRC, that is what has prevented us
from actually ever doing this up to now.


Phil


>
> Thoughts?
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] Overlap; Collections thoughts

Paul Benedict
I do not like the divide between Lang and Collections. I think it's a
superficial divide that can never really be complete, and the forces
of logic naturally pulls us back together in some regards. It's
consternation to keep these projects separate. Why must we keep
trying?

I'd like to propose merging the projects and then breaking them down
into separate Maven child modules (i.e., distribution assemblies). I'd
rather have one release with smaller artifacts. Perhaps we can do this
for Commons Lang 3 (or, if we must, wait till 4).

Paul

On Sat, Jan 2, 2010 at 11:11 AM, Phil Steitz <[hidden email]> wrote:

> Henri Yandell wrote:
>> Overlap between Lang and Collections is starting to increase a bit.
>> Requested items for ArrayUtils (LANG-238, LANG-470) are better
>> implemented imo as an ArraySet class. An easy add to Collections.
>>
>> ComparableComparator made its way (privately) over for the new Range
>> class. Fair enough - Comparable and Comparator also overlap between
>> lang.* and util.*.
>>
>> I have a JIRA issue threat to consider moving Collections code over to
>> Lang if Collections becomes dead [LANG-532]  :)
>>
>> ---
>>
>> One thought I have for Collections is splitting it up into two parts.
>> The first would be items that add to collections in the JDK, the
>> second would be additional collections. The former could conceivably
>> merge with Lang, the latter could also be split up into an SPI style
>> approach with an API jar and an Impl jar. The latter would most likely
>> depend on the former.
>>
>> It would then be tempting to also merge Functors for example into the
>> latter, plus I think we could get back on the bandwagon of adding new
>> things, like the long standing Trie JIRA issue.
>>
>> Biased note: Part of this is that I'm interested in the JDK enhancing
>> parts, but not all the implementations of weird and whacky
>> collections; however I think this is likely not just me and that the
>> separation would do wonders for the release cycle.
>
> Interesting idea and forces us to really think about the scopes of
> both [lang] and [collections].  Both started as really extensions of
> the JDK and both have had large parts obsoleted by advances in the
> JDK.  I guess it still makes sense to consider [lang] as simple
> extensions of the JDK and [collections] as data structures.  What I
> have a little trouble with is where to draw the line within
> [collections].  I think functors is a bad example, as one could
> argue that this belongs in neither [collections] nor [lang] - oh
> wait, we did that and created [functors] (lets not divert down that
> rabbit hole ;).  Better examples of what might be peeled off into
> [lang] could be the iterators or decorators.  Can you get a little
> more specific on what parts of [collections] you see as in scope for
>  merging into [lang]?
>
> I am +1 on publishing the collections test jar as a separate maven
> artifact.  We don't have to create a separate subproject for that, IMO.
>
> Note that lots of other commons components - [math], [net],
> [functors], [configuration], [beanutils] all come to mind
> immediately - have elements that amount to extensions of the JDK.
> Like [collections], they all have a more specialized domain that is
> their primary focus.  So the natural question is, if this makes
> sense for [collections], why not everywhere else?  Answering that
> question might help clarify intent here.
>
> One final comment is that a logical alternative is to just split
> [collections] internally into multiple pieces with separate release
> cycles. Managing dependencies among the subcomponents and user
> documentation might be tricky.  IIRC, that is what has prevented us
> from actually ever doing this up to now.
>
>
> Phil
>
>
>>
>> Thoughts?
>>
>> Hen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] Overlap; Collections thoughts

Henri Yandell
In reply to this post by Phil Steitz
On Sat, Jan 2, 2010 at 9:11 AM, Phil Steitz <[hidden email]> wrote:

> Henri Yandell wrote:
>> Overlap between Lang and Collections is starting to increase a bit.
>> Requested items for ArrayUtils (LANG-238, LANG-470) are better
>> implemented imo as an ArraySet class. An easy add to Collections.
>>
>> ComparableComparator made its way (privately) over for the new Range
>> class. Fair enough - Comparable and Comparator also overlap between
>> lang.* and util.*.
>>
>> I have a JIRA issue threat to consider moving Collections code over to
>> Lang if Collections becomes dead [LANG-532]  :)
>>
>> ---
>>
>> One thought I have for Collections is splitting it up into two parts.
>> The first would be items that add to collections in the JDK, the
>> second would be additional collections. The former could conceivably
>> merge with Lang, the latter could also be split up into an SPI style
>> approach with an API jar and an Impl jar. The latter would most likely
>> depend on the former.
>>
>> It would then be tempting to also merge Functors for example into the
>> latter, plus I think we could get back on the bandwagon of adding new
>> things, like the long standing Trie JIRA issue.
>>
>> Biased note: Part of this is that I'm interested in the JDK enhancing
>> parts, but not all the implementations of weird and whacky
>> collections; however I think this is likely not just me and that the
>> separation would do wonders for the release cycle.
>
> Interesting idea and forces us to really think about the scopes of
> both [lang] and [collections].  Both started as really extensions of
> the JDK and both have had large parts obsoleted by advances in the
> JDK.  I guess it still makes sense to consider [lang] as simple
> extensions of the JDK and [collections] as data structures.  What I
> have a little trouble with is where to draw the line within
> [collections].

Agreed - both in terms of what we consider a simple extension of the
JDK and what we consider a data structure/algorithm.

> I think functors is a bad example, as one could
> argue that this belongs in neither [collections] nor [lang] - oh
> wait, we did that and created [functors] (lets not divert down that
> rabbit hole ;).

I was thinking more that a smaller [collections] might have room for
the functor code again - not that [lang] would :) Agreed that it's
better out than in though.

> Better examples of what might be peeled off into
> [lang] could be the iterators or decorators.  Can you get a little
> more specific on what parts of [collections] you see as in scope for
>  merging into [lang]?

https://issues.apache.org/jira/browse/LANG-532 has a bit.

The various XxxUtils classes - but not the factory builder parts that
supply various aspects.
A slice of the iterators and the comparators. Possibly some basic
'missing' implementations such as ArrayStack, ArraySet, FastVector
etc.

Not in scope - bag, buffer, transformer,

> I am +1 on publishing the collections test jar as a separate maven
> artifact.  We don't have to create a separate subproject for that, IMO.
>
> Note that lots of other commons components - [math], [net],
> [functors], [configuration], [beanutils] all come to mind
> immediately - have elements that amount to extensions of the JDK.

[io] and [codec] are the ones that jump to mind for me, but I think
they're both still tight enough in scope that a) the committer style
is not different and b) it's not a big brain import for the users to
grok the component. Again though there's a similar style of FooUtils
classes  on top of the JDK mixed with SPI type implementations.

[beanutils] always feels like it needs replacing - something smaller
and tighter in [lang] could be a successor.

> Like [collections], they all have a more specialized domain that is
> their primary focus.  So the natural question is, if this makes
> sense for [collections], why not everywhere else?  Answering that
> question might help clarify intent here.

Yup. We've already been doing it with BeanUtils - some of the code
moved/copied over in 3.0.

What it would possibly mean in your commons wide suggestion is a bunch
of components having a dependency on [lang], which as you say below
has often been a blocker. Then again - all java.* code depends on
java.lang.* :)

> One final comment is that a logical alternative is to just split
> [collections] internally into multiple pieces with separate release
> cycles. Managing dependencies among the subcomponents and user
> documentation might be tricky.  IIRC, that is what has prevented us
> from actually ever doing this up to now.

Yup. Effectively this is both a split into 'Collections JDK' and
'Collections Structures', and a merge of Collections JDK to Lang.

To Paul's email - I think a wholesale merge of Collections and Lang
would be too much. It would slow down releases when we need to release
more often (that being part of my justification for splitting
Collections - the two halves would be quicker to release). I think
that  similarity of scope within a component makes it more releasable
- the hardest part of Lang 3.0 is the builder subpackage, and I think
that's because it's a different style of code than much of the rest.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] Overlap; Collections thoughts

Henri Yandell
On Sat, Jan 2, 2010 at 10:02 AM, Henri Yandell <[hidden email]> wrote:
> On Sat, Jan 2, 2010 at 9:11 AM, Phil Steitz <[hidden email]> wrote:

>> One final comment is that a logical alternative is to just split
>> [collections] internally into multiple pieces with separate release
>> cycles. Managing dependencies among the subcomponents and user
>> documentation might be tricky.  IIRC, that is what has prevented us
>> from actually ever doing this up to now.
>
> Yup. Effectively this is both a split into 'Collections JDK' and
> 'Collections Structures', and a merge of Collections JDK to Lang.

Thinking further...

One thing I don't like it is holding Lang 3.0 up. Or the big leap that
Collections JDK would go into Lang; that may not feel right once we
get there.

So perhaps the solution is to do the Collections split of JDK and
Structures/Algorithms in 4.0, and think about merging later:

Lang 3.0
Collections Core 4.0
Collection Data Structures/Algorithms 4.0

or some set of better names. With Core 4.0 possibly merging into Lang
3.1 etc if it felt right.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] Overlap; Collections thoughts

Phil Steitz
In reply to this post by Henri Yandell
Henri Yandell wrote:

> On Sat, Jan 2, 2010 at 9:11 AM, Phil Steitz <[hidden email]> wrote:
>> Henri Yandell wrote:
>>> Overlap between Lang and Collections is starting to increase a bit.
>>> Requested items for ArrayUtils (LANG-238, LANG-470) are better
>>> implemented imo as an ArraySet class. An easy add to Collections.
>>>
>>> ComparableComparator made its way (privately) over for the new Range
>>> class. Fair enough - Comparable and Comparator also overlap between
>>> lang.* and util.*.
>>>
>>> I have a JIRA issue threat to consider moving Collections code over to
>>> Lang if Collections becomes dead [LANG-532]  :)
>>>
>>> ---
>>>
>>> One thought I have for Collections is splitting it up into two parts.
>>> The first would be items that add to collections in the JDK, the
>>> second would be additional collections. The former could conceivably
>>> merge with Lang, the latter could also be split up into an SPI style
>>> approach with an API jar and an Impl jar. The latter would most likely
>>> depend on the former.
>>>
>>> It would then be tempting to also merge Functors for example into the
>>> latter, plus I think we could get back on the bandwagon of adding new
>>> things, like the long standing Trie JIRA issue.
>>>
>>> Biased note: Part of this is that I'm interested in the JDK enhancing
>>> parts, but not all the implementations of weird and whacky
>>> collections; however I think this is likely not just me and that the
>>> separation would do wonders for the release cycle.
>> Interesting idea and forces us to really think about the scopes of
>> both [lang] and [collections].  Both started as really extensions of
>> the JDK and both have had large parts obsoleted by advances in the
>> JDK.  I guess it still makes sense to consider [lang] as simple
>> extensions of the JDK and [collections] as data structures.  What I
>> have a little trouble with is where to draw the line within
>> [collections].
>
> Agreed - both in terms of what we consider a simple extension of the
> JDK and what we consider a data structure/algorithm.
>
>>  I think functors is a bad example, as one could
>> argue that this belongs in neither [collections] nor [lang] - oh
>> wait, we did that and created [functors] (lets not divert down that
>> rabbit hole ;).
>
> I was thinking more that a smaller [collections] might have room for
> the functor code again - not that [lang] would :) Agreed that it's
> better out than in though.

That is instructive, but sort of hurts the case, though, as functors
are arguably closer to a language extension than they are related to
the [collections] domain.

>
>>  Better examples of what might be peeled off into
>> [lang] could be the iterators or decorators.  Can you get a little
>> more specific on what parts of [collections] you see as in scope for
>>  merging into [lang]?
>
> https://issues.apache.org/jira/browse/LANG-532 has a bit.
>
> The various XxxUtils classes - but not the factory builder parts that
> supply various aspects.
> A slice of the iterators and the comparators. Possibly some basic
> 'missing' implementations such as ArrayStack, ArraySet, FastVector
> etc.
>

So its the bits that connect the domain to the JDK?  That would put,
for example, parts of o.a.c.math.stat.StatUtils,
o.a.c.math.util.MathUtils similarly in scope.  The question here is
what is special about [collections] and doesn't this just amount to
artificially hacking off pieces that belong with the domain?  I am
still not seeing the "joints" here.

> Not in scope - bag, buffer, transformer,
>
>> I am +1 on publishing the collections test jar as a separate maven
>> artifact.  We don't have to create a separate subproject for that, IMO.
>>
>> Note that lots of other commons components - [math], [net],
>> [functors], [configuration], [beanutils] all come to mind
>> immediately - have elements that amount to extensions of the JDK.
>
> [io] and [codec] are the ones that jump to mind for me, but I think
> they're both still tight enough in scope that a) the committer style
> is not different and b) it's not a big brain import for the users to
> grok the component. Again though there's a similar style of FooUtils
> classes  on top of the JDK mixed with SPI type implementations.
>
> [beanutils] always feels like it needs replacing - something smaller
> and tighter in [lang] could be a successor.
>
>> Like [collections], they all have a more specialized domain that is
>> their primary focus.  So the natural question is, if this makes
>> sense for [collections], why not everywhere else?  Answering that
>> question might help clarify intent here.
>
> Yup. We've already been doing it with BeanUtils - some of the code
> moved/copied over in 3.0.
>
> What it would possibly mean in your commons wide suggestion is a bunch
> of components having a dependency on [lang], which as you say below
> has often been a blocker. Then again - all java.* code depends on
> java.lang.* :)

Can you explain a little more what exactly has moved from BeanUtils
and what kinds of other things you have in mind?

>
>> One final comment is that a logical alternative is to just split
>> [collections] internally into multiple pieces with separate release
>> cycles. Managing dependencies among the subcomponents and user
>> documentation might be tricky.  IIRC, that is what has prevented us
>> from actually ever doing this up to now.
>
> Yup. Effectively this is both a split into 'Collections JDK' and
> 'Collections Structures', and a merge of Collections JDK to Lang.

A natural question to ask is is that the best way to split
[collections] up?  It would probably force some users to depend on -
and look for stuff in - [lang] when [collections] by itself would
now meet their needs.  Pulling the iterators, for example, out of
[collections] would make it harder to use by itself and I bet would
force [collections] itself to depend on [lang].  I am not (yet)
convinced that this is the best way to divide [collections].

Phil

>
> To Paul's email - I think a wholesale merge of Collections and Lang
> would be too much. It would slow down releases when we need to release
> more often (that being part of my justification for splitting
> Collections - the two halves would be quicker to release). I think
> that  similarity of scope within a component makes it more releasable
> - the hardest part of Lang 3.0 is the builder subpackage, and I think
> that's because it's a different style of code than much of the rest.
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] Overlap; Collections thoughts

Paul Benedict
Each if you split Collections into Maven children, you would still
wouldn't want to release them independently. That would be a gigantic
administrative error. Struts was thinking about doing the same thing
with its libraries, but we turned away from it -- THANKFULLY. How
would you explain to users what versions are compatible with each
other? It becomes a nightmare to manage.

Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] Overlap; Collections thoughts

Henri Yandell
In reply to this post by Phil Steitz
On Sat, Jan 2, 2010 at 10:45 AM, Phil Steitz <[hidden email]> wrote:
> Henri Yandell wrote:

>> I was thinking more that a smaller [collections] might have room for
>> the functor code again - not that [lang] would :) Agreed that it's
>> better out than in though.
>
> That is instructive, but sort of hurts the case, though, as functors
> are arguably closer to a language extension than they are related to
> the [collections] domain.

Agreed that it's a bad example. I'd used it as a component that had
left collections for some reason and might be a better fit - not from
a technical perspective. My negative to adding to Lang would be that
unlike the Enum and NestedException pieces of code, functional-in-OO
needs a lot of language support to feel good.

>>>  Better examples of what might be peeled off into
>>> [lang] could be the iterators or decorators.  Can you get a little
>>> more specific on what parts of [collections] you see as in scope for
>>>  merging into [lang]?
>>
>> https://issues.apache.org/jira/browse/LANG-532 has a bit.
>>
>> The various XxxUtils classes - but not the factory builder parts that
>> supply various aspects.
>> A slice of the iterators and the comparators. Possibly some basic
>> 'missing' implementations such as ArrayStack, ArraySet, FastVector
>> etc.
>>
>
> So its the bits that connect the domain to the JDK?  That would put,
> for example, parts of o.a.c.math.stat.StatUtils,
> o.a.c.math.util.MathUtils similarly in scope.  The question here is
> what is special about [collections] and doesn't this just amount to
> artificially hacking off pieces that belong with the domain?  I am
> still not seeing the "joints" here.

Lang's math.NumberUtils and math.Fraction for example. MathUtils and a
little bit of StatUtils do look to be similar in scope.

The special bits with collections are:

* Lang issues are identifying overlap problems with Collections.
ArrayUtils starts to look like Collections when you take a more
generic approach to a problem (for example ArraySet),
ComparableComparator was recently copied over (private class) and
there is a ComparableUtils class request.
* I have concerns over whether there will be a Collections 4.0.
* Collections has issues that say (paraphrasing) "Nice idea, don't
commit until Collections is lighter in weight".
* Collections has more code at the JDK level being hidden by more
additional features than say IO (less additional features), Codec (not
a lot of JDK level code), Math (not a lot of JDK level code).

>>> Like [collections], they all have a more specialized domain that is
>>> their primary focus.  So the natural question is, if this makes
>>> sense for [collections], why not everywhere else?  Answering that
>>> question might help clarify intent here.
>>
>> Yup. We've already been doing it with BeanUtils - some of the code
>> moved/copied over in 3.0.
>>
>> What it would possibly mean in your commons wide suggestion is a bunch
>> of components having a dependency on [lang], which as you say below
>> has often been a blocker. Then again - all java.* code depends on
>> java.lang.* :)
>
> Can you explain a little more what exactly has moved from BeanUtils
> and what kinds of other things you have in mind?

I thought the new reflect package was from BeanUtils. I think by way
of the reflect sandbox component. If not code from BeanUtils, it is a
direct overlap with some of the code at the core of BeanUtils.

>>> One final comment is that a logical alternative is to just split
>>> [collections] internally into multiple pieces with separate release
>>> cycles. Managing dependencies among the subcomponents and user
>>> documentation might be tricky.  IIRC, that is what has prevented us
>>> from actually ever doing this up to now.
>>
>> Yup. Effectively this is both a split into 'Collections JDK' and
>> 'Collections Structures', and a merge of Collections JDK to Lang.
>
> A natural question to ask is is that the best way to split
> [collections] up?  It would probably force some users to depend on -
> and look for stuff in - [lang] when [collections] by itself would
> now meet their needs.  Pulling the iterators, for example, out of
> [collections] would make it harder to use by itself and I bet would
> force [collections] itself to depend on [lang].  I am not (yet)
> convinced that this is the best way to divide [collections].

Taking things to the logical conclusion you suggest (lots of
components pushing down into [lang]) would definitely end up with
[lang] as a low level dependency of all. Nice in some ways, not in
others. We could definitely use a jarjar type thing there if we got
serious on the subject.

In terms of things depending...

Removing comparators from Collections would leave PriorityBuffer and
TransformingComparator both wanting ComparableComparator. Lang also
uses that - given that java.lang.Comparable fits in Lang and
java.util.Comparator is taken to fit in Collections I think the
overlap problem here is 'fine' - i.e. outside our control. This is the
main part I began with.

For Iterators - I agree. The same would be true of the various
XxxUtils classes. How much does the rest of Collections depend on
them. I suspect the painful part would be the most useful bits, rather
than idiosyncrasies. There are also features that I think are less
useful and more theoretical. ArrayListIterator on top of ArrayIterator
- driven more by the concept of ListIterator and ResettableIterator
(imo).

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] Overlap; Collections thoughts

Henri Yandell
In reply to this post by Paul Benedict
On Sat, Jan 2, 2010 at 12:36 PM, Paul Benedict <[hidden email]> wrote:
> Each if you split Collections into Maven children, you would still
> wouldn't want to release them independently. That would be a gigantic
> administrative error. Struts was thinking about doing the same thing
> with its libraries, but we turned away from it -- THANKFULLY. How
> would you explain to users what versions are compatible with each
> other? It becomes a nightmare to manage.

Both extreme options are nightmares imo. Holding everything up while
you to release everything in sync is painful too. Struts has the
advantage of a common entry point already.

I would be tempted to schedule major upgrade cycles, while having
minor ones run independently. Still tricky to do, and hurts
innovation. Then again - having a scheduled 'v4.0 of all Commons
components will now be available to be worked on' time might make
innovation happen more easily.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] Overlap; Collections thoughts

Paul Benedict
In reply to this post by Henri Yandell
Henri,

> Lang's math.NumberUtils and math.Fraction for example. MathUtils and a
> little bit of StatUtils do look to be similar in scope.

I have voiced booting the whole math package from Commons Lang.
Anytime another project inches its way into another, that's my signal
its poorly placed. I still think for Lang 3.0, the math package should
leave. If people want mathematical stuff, Commons Math is there place.

Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] Overlap; Collections thoughts

Paul Benedict
In reply to this post by Henri Yandell
Henri,

> I would be tempted to schedule major upgrade cycles, while having
> minor ones run independently. Still tricky to do, and hurts
> innovation. Then again - having a scheduled 'v4.0 of all Commons
> components will now be available to be worked on' time might make
> innovation happen more easily.

I don't think the way Lang and Collections does their artifacts is a
problem... BUT, I do say they stuff way too much stuff into a release.
Their cycles are slow because they cram a mountain into each release.
Rather, release often and release less. Do something like 20 issues a
release and call it a day.

Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] Overlap; Collections thoughts

Henri Yandell
On Sat, Jan 2, 2010 at 1:34 PM, Paul Benedict <[hidden email]> wrote:

> Henri,
>
>> I would be tempted to schedule major upgrade cycles, while having
>> minor ones run independently. Still tricky to do, and hurts
>> innovation. Then again - having a scheduled 'v4.0 of all Commons
>> components will now be available to be worked on' time might make
>> innovation happen more easily.
>
> I don't think the way Lang and Collections does their artifacts is a
> problem... BUT, I do say they stuff way too much stuff into a release.
> Their cycles are slow because they cram a mountain into each release.
> Rather, release often and release less. Do something like 20 issues a
> release and call it a day.

Absolutely. I want 3.0 out as a baseline, but after that my resolution
is to do my part in having Lang release every quarter or more often.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] Overlap; Collections thoughts

Matt Benson-2
In reply to this post by Henri Yandell

On Jan 2, 2010, at 3:27 PM, Henri Yandell wrote:

> On Sat, Jan 2, 2010 at 10:45 AM, Phil Steitz  
> <[hidden email]> wrote:
>> Henri Yandell wrote:
>
>>> I was thinking more that a smaller [collections] might have room for
>>> the functor code again - not that [lang] would :) Agreed that it's
>>> better out than in though.
>>
>> That is instructive, but sort of hurts the case, though, as functors
>> are arguably closer to a language extension than they are related to
>> the [collections] domain.
>
> Agreed that it's a bad example. I'd used it as a component that had
> left collections for some reason and might be a better fit - not from
> a technical perspective. My negative to adding to Lang would be that
> unlike the Enum and NestedException pieces of code, functional-in-OO
> needs a lot of language support to feel good.
>
>>>>  Better examples of what might be peeled off into
>>>> [lang] could be the iterators or decorators.  Can you get a little
>>>> more specific on what parts of [collections] you see as in scope  
>>>> for
>>>>  merging into [lang]?
>>>
>>> https://issues.apache.org/jira/browse/LANG-532 has a bit.
>>>
>>> The various XxxUtils classes - but not the factory builder parts  
>>> that
>>> supply various aspects.
>>> A slice of the iterators and the comparators. Possibly some basic
>>> 'missing' implementations such as ArrayStack, ArraySet, FastVector
>>> etc.
>>>
>>
>> So its the bits that connect the domain to the JDK?  That would put,
>> for example, parts of o.a.c.math.stat.StatUtils,
>> o.a.c.math.util.MathUtils similarly in scope.  The question here is
>> what is special about [collections] and doesn't this just amount to
>> artificially hacking off pieces that belong with the domain?  I am
>> still not seeing the "joints" here.
>
> Lang's math.NumberUtils and math.Fraction for example. MathUtils and a
> little bit of StatUtils do look to be similar in scope.
>
> The special bits with collections are:
>
> * Lang issues are identifying overlap problems with Collections.
> ArrayUtils starts to look like Collections when you take a more
> generic approach to a problem (for example ArraySet),
> ComparableComparator was recently copied over (private class) and
> there is a ComparableUtils class request.
> * I have concerns over whether there will be a Collections 4.0.

My view on this is "eventually"--I certainly feel I've put in too  
much work to simply let [collections] go.  However, the following  
issue you identified has been a thorn in my side for quite some time  
so I am on board for streamlining, multiple artifacts, and anything  
else that will improve the situation.

> * Collections has issues that say (paraphrasing) "Nice idea, don't
> commit until Collections is lighter in weight".
> * Collections has more code at the JDK level being hidden by more
> additional features than say IO (less additional features), Codec (not
> a lot of JDK level code), Math (not a lot of JDK level code).
>
>>>> Like [collections], they all have a more specialized domain that is
>>>> their primary focus.  So the natural question is, if this makes
>>>> sense for [collections], why not everywhere else?  Answering that
>>>> question might help clarify intent here.
>>>
>>> Yup. We've already been doing it with BeanUtils - some of the code
>>> moved/copied over in 3.0.
>>>
>>> What it would possibly mean in your commons wide suggestion is a  
>>> bunch
>>> of components having a dependency on [lang], which as you say below
>>> has often been a blocker. Then again - all java.* code depends on
>>> java.lang.* :)
>>
>> Can you explain a little more what exactly has moved from BeanUtils
>> and what kinds of other things you have in mind?
>
> I thought the new reflect package was from BeanUtils. I think by way
> of the reflect sandbox component. If not code from BeanUtils, it is a
> direct overlap with some of the code at the core of BeanUtils.

That code was indeed cloned/copied from BeanUtils.  The [reflect]  
component in the sandbox didn't figure into the pedigree, though some  
of the class names there would understandably suggest otherwise (or,  
for all I know [reflect] may have also been cloned from BeanUtils  
code).  The point being that oacl.reflect provides a thin veneer over  
java.lang.reflect and thus seemed to be a proper fit.

-Matt

>
>>>> One final comment is that a logical alternative is to just split
>>>> [collections] internally into multiple pieces with separate release
>>>> cycles. Managing dependencies among the subcomponents and user
>>>> documentation might be tricky.  IIRC, that is what has prevented us
>>>> from actually ever doing this up to now.
>>>
>>> Yup. Effectively this is both a split into 'Collections JDK' and
>>> 'Collections Structures', and a merge of Collections JDK to Lang.
>>
>> A natural question to ask is is that the best way to split
>> [collections] up?  It would probably force some users to depend on -
>> and look for stuff in - [lang] when [collections] by itself would
>> now meet their needs.  Pulling the iterators, for example, out of
>> [collections] would make it harder to use by itself and I bet would
>> force [collections] itself to depend on [lang].  I am not (yet)
>> convinced that this is the best way to divide [collections].
>
> Taking things to the logical conclusion you suggest (lots of
> components pushing down into [lang]) would definitely end up with
> [lang] as a low level dependency of all. Nice in some ways, not in
> others. We could definitely use a jarjar type thing there if we got
> serious on the subject.
>
> In terms of things depending...
>
> Removing comparators from Collections would leave PriorityBuffer and
> TransformingComparator both wanting ComparableComparator. Lang also
> uses that - given that java.lang.Comparable fits in Lang and
> java.util.Comparator is taken to fit in Collections I think the
> overlap problem here is 'fine' - i.e. outside our control. This is the
> main part I began with.
>
> For Iterators - I agree. The same would be true of the various
> XxxUtils classes. How much does the rest of Collections depend on
> them. I suspect the painful part would be the most useful bits, rather
> than idiosyncrasies. There are also features that I think are less
> useful and more theoretical. ArrayListIterator on top of ArrayIterator
> - driven more by the concept of ListIterator and ResettableIterator
> (imo).
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] Overlap; Collections thoughts

Phil Steitz
In reply to this post by Paul Benedict
Paul Benedict wrote:
> Each if you split Collections into Maven children, you would still
> wouldn't want to release them independently. That would be a gigantic
> administrative error. Struts was thinking about doing the same thing
> with its libraries, but we turned away from it -- THANKFULLY. How
> would you explain to users what versions are compatible with each
> other? It becomes a nightmare to manage.

That is a very good point.  It would only be possible to separate
the release cycles if you could somehow guarantee that mixing and
matching subcomponent versions would *always* work, which is
probably impractical.

I think your later suggestion is a better way to go - keep doing
bundled releases, but do them more often.

Phil
>
> Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] Overlap; Collections thoughts

Stephen Colebourne
In reply to this post by Henri Yandell
There are many good points in this thread. My input is to try and
outline where I have seen te boundaries.

[lang] vs [math] - [lang] doesn't require a maths degree. [math] does.

[lang] vs [functor] - [lang] doesn't require FP knowledge or religion.
[functor] does.

[io] - handles Stream, Reader and Writer - the java.io package

[collections] - handles those interfaces defined by Sun as the Java
Collections Framework

[beanutils] - handles code that adheres to Sun's defined Java Bean framewok

[lang] - the remaining parts of java.lang and java.util

Oh, and as per the original commons charter, DUPLICATION IS FINE!
There is nothing fundamentally wrong with small amounts of duplication
in low level commons classes, and this is far preferable to te
unacceptable idea of dependencies.

Thus, Fraction can happily live in [lang] and [math] - no great harm
comes fom it ([math] targets a smaller group of developers than [lang]).

ArrayUtils? Well arrays are not part of the Java Collections Framework.
So, its fair for array handling code to be in [lang].

And splitting [collections]? Definitely a good idea. I would remove all
the Predicate/Closure/Transformer code (if you believe in FP, use
[functor]). Then split the rest by implementations of JDK collections,
and extended JDK collections - BidiMap, Bag, Trie.

Stephen


Henri Yandell wrote:

> Overlap between Lang and Collections is starting to increase a bit.
> Requested items for ArrayUtils (LANG-238, LANG-470) are better
> implemented imo as an ArraySet class. An easy add to Collections.
>
> ComparableComparator made its way (privately) over for the new Range
> class. Fair enough - Comparable and Comparator also overlap between
> lang.* and util.*.
>
> I have a JIRA issue threat to consider moving Collections code over to
> Lang if Collections becomes dead [LANG-532]  :)
>
> ---
>
> One thought I have for Collections is splitting it up into two parts.
> The first would be items that add to collections in the JDK, the
> second would be additional collections. The former could conceivably
> merge with Lang, the latter could also be split up into an SPI style
> approach with an API jar and an Impl jar. The latter would most likely
> depend on the former.
>
> It would then be tempting to also merge Functors for example into the
> latter, plus I think we could get back on the bandwagon of adding new
> things, like the long standing Trie JIRA issue.
>
> Biased note: Part of this is that I'm interested in the JDK enhancing
> parts, but not all the implementations of weird and whacky
> collections; however I think this is likely not just me and that the
> separation would do wonders for the release cycle.
>
> Thoughts?
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] Overlap; Collections thoughts

Matt Benson-2

On Jan 5, 2010, at 7:58 PM, Stephen Colebourne wrote:
[SNIP]
> And splitting [collections]? Definitely a good idea. I would remove  
> all the Predicate/Closure/Transformer code (if you believe in FP,  
> use [functor]). Then split the rest by implementations of JDK  
> collections, and extended JDK collections - BidiMap, Bag, Trie.
>

+1 as I doubt any more reasonable approach exists.

-Matt

> Stephen
>
>
> Henri Yandell wrote:
>> Overlap between Lang and Collections is starting to increase a bit.
>> Requested items for ArrayUtils (LANG-238, LANG-470) are better
>> implemented imo as an ArraySet class. An easy add to Collections.
>> ComparableComparator made its way (privately) over for the new Range
>> class. Fair enough - Comparable and Comparator also overlap between
>> lang.* and util.*.
>> I have a JIRA issue threat to consider moving Collections code  
>> over to
>> Lang if Collections becomes dead [LANG-532]  :)
>> ---
>> One thought I have for Collections is splitting it up into two parts.
>> The first would be items that add to collections in the JDK, the
>> second would be additional collections. The former could conceivably
>> merge with Lang, the latter could also be split up into an SPI style
>> approach with an API jar and an Impl jar. The latter would most  
>> likely
>> depend on the former.
>> It would then be tempting to also merge Functors for example into the
>> latter, plus I think we could get back on the bandwagon of adding new
>> things, like the long standing Trie JIRA issue.
>> Biased note: Part of this is that I'm interested in the JDK enhancing
>> parts, but not all the implementations of weird and whacky
>> collections; however I think this is likely not just me and that the
>> separation would do wonders for the release cycle.
>> Thoughts?
>> Hen
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12