[jira] Commented: (COLLECTIONS-110) [collections] Support parametized classes with commons.collections.
[ http://issues.apache.org/jira/browse/COLLECTIONS-110?page=comments#action_12415442 ] Sergei Ivanov commented on COLLECTIONS-110: --- Just had a look at it, and have a feeling that the second SF project is much, much better than the first one. Still, it is more rigid (regarding the use of generics) in many places than it should have been imho. For example, instead of: TransformingComparator(TransformerI,O transformer, ComparatorO decorated) ...I would go for a more relaxed version: TransformingComparator(Transformer? super I, ? extends O transformer, Comparator? super O decorated) So that the following is possible: ComparatorDouble c = new TransformingComparatorDouble, Comparable( StringValueTransformer.getInstance(), ComparableComparator.getInstance() ); Am I paranoid? [collections] Support parametized classes with commons.collections. --- Key: COLLECTIONS-110 URL: http://issues.apache.org/jira/browse/COLLECTIONS-110 Project: Commons Collections Type: Bug Environment: Operating System: other Platform: Other Reporter: Colbert Philippe It's time to create a parallel version of commons.collections to support parametized classes of each container class and abstract class. It's not that hard. There is a 23 PDF document on Sun Java website describing in detail how it should be done and what to watch out for. I already converted a few classes from commons.collection privately for my own needs. Once you get the hang of it, it's a rather quick process. I am even willing to volunteer my time to do some more but I need the collaboration of some of the original programmers to watch over things. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-110) [collections] Support parametized classes with commons.collections.
[ http://issues.apache.org/jira/browse/COLLECTIONS-110?page=comments#action_12414272 ] Sergei Ivanov commented on COLLECTIONS-110: --- The choice to use new packages was I believe a recommendation from us, so as to ensure that both the generic and non-generic versions can be in the classpath at the same time. If they only renamed org.apache.commons.collections to net.sf.collections15, that would still be manageable. However, what I was pointing to is, for example, that all predicates were moved from ...functors package under net.sf.collections15.functors.predicate package. Also, some new classes were introduced (e.g. AbstractPredicateDecorator, although in my opinion it's well justified, because it reduces code duplication). Such divergence will make propagation of changes/fixes from classic collections much more difficult. [collections] Support parametized classes with commons.collections. --- Key: COLLECTIONS-110 URL: http://issues.apache.org/jira/browse/COLLECTIONS-110 Project: Commons Collections Type: Bug Environment: Operating System: other Platform: Other Reporter: Colbert Philippe It's time to create a parallel version of commons.collections to support parametized classes of each container class and abstract class. It's not that hard. There is a 23 PDF document on Sun Java website describing in detail how it should be done and what to watch out for. I already converted a few classes from commons.collection privately for my own needs. Once you get the hang of it, it's a rather quick process. I am even willing to volunteer my time to do some more but I need the collaboration of some of the original programmers to watch over things. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-110) [collections] Support parametized classes with commons.collections.
[ http://issues.apache.org/jira/browse/COLLECTIONS-110?page=comments#action_12414304 ] Sergei Ivanov commented on COLLECTIONS-110: --- Another problem we are going to face is that some of the current implementation decisions are not compatible with generics. First of all, static singleton instances of e.g. various EmptyIterator's and trivial functors cannot be made generic. They can be wrapped in a static generified getInstance() method, which would still contain an unchecked cast. Second, there are many graceful fallback cases, which become tricky with generics. Let's take TransformIterator as an example. Constructing it without a transformer is equivalent to constructing it with a NOPTransformer. However, NOPTransformer introduces a certain relation between expected input and output types: output type must be assignable from input type. There is no such relation (in fact, no relation at all) between generic parameter types for generic Transformer interface. [collections] Support parametized classes with commons.collections. --- Key: COLLECTIONS-110 URL: http://issues.apache.org/jira/browse/COLLECTIONS-110 Project: Commons Collections Type: Bug Environment: Operating System: other Platform: Other Reporter: Colbert Philippe It's time to create a parallel version of commons.collections to support parametized classes of each container class and abstract class. It's not that hard. There is a 23 PDF document on Sun Java website describing in detail how it should be done and what to watch out for. I already converted a few classes from commons.collection privately for my own needs. Once you get the hang of it, it's a rather quick process. I am even willing to volunteer my time to do some more but I need the collaboration of some of the original programmers to watch over things. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-181) [collections] [PATCH] Provide maps with direct indexed access to the entries
[ http://issues.apache.org/jira/browse/COLLECTIONS-181?page=all ] Sergei Ivanov updated COLLECTIONS-181: -- Attachment: indexed_map-1_1_1.zip The original version of the patch was developed against commons-collections 3.1. Now 3.2 is the latest stable release and I updated the patched files accordingly. [collections] [PATCH] Provide maps with direct indexed access to the entries Key: COLLECTIONS-181 URL: http://issues.apache.org/jira/browse/COLLECTIONS-181 Project: Commons Collections Type: Improvement Versions: 3.1 Environment: Operating System: Windows XP Platform: PC Reporter: Sergei S. Ivanov Priority: Minor Attachments: IndexedSortedMap.emptyCollection.version3.2.obj, IndexedSortedMap.fullCollection.version3.2.obj, IndexedSortedMap.java, TestIndexedSortedMap.java, indexed_map-1_1.zip, indexed_map-1_1_1.zip, indexed_map.zip When I was implementing a new part of our large system I needed a sorted map, where keys and corresponding values could also be accessed directly by index (as in array or List). Both keyed and indexed access methods had to be efficient, while insertions or removals needn't to be. I was amazed to find absolutely no ready-to-use implementations, that's why I decided to create my own. I created a sorted map, which uses array as a backend storage. I borrowed some internal implementation ideas from java.util.ArrayList, java.util.TreeMap and org.apache.commons.collections.map.AbstractHashedMap and LinkedMap. See attachment. I hope you will find the idea useful. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-110) [collections] Support parametized classes with commons.collections.
[
http://issues.apache.org/jira/browse/COLLECTIONS-110?page=comments#action_12413907
]
Sergei Ivanov commented on COLLECTIONS-110:
---
[cross-posted from Bugzilla]
--- Additional Comment #6 From Sergei S. Ivanov 2006-05-22 21:49 [reply]
---
(In reply to comment #4)
The project was done without good technical knowledge of Java 1.5
parametized
classes.
THE TYPICAL ERROR:
class SetE {
void add(E d) {...} // that's wrong!!!
}
- the method add should read
void add(? extends E d) {...} // so any subclass of E is acceptable.
I am sorry to disappoint you, but the code above is not wrong. add(E) will
accept any subclass of actual type argument. The example below is fully
legitimate:
SetNumber set = new HashSetNumber();
set.add(new Double(0));
Please have a look, how SetE interface is defined in the JDK.
As for the wildcards (? extends/super E), they are mostly needed, when you
have generic objects being passed into/returned from methods. Remember that
you cannot pass object, which is declared as SetDouble, to a function that
accepts a SetNumber as an argument, but you can do it if the argument type
is declared as Set? extends Number.
Without any aim to offend you, I would strongly recommend you revisiting the
tutorial you mentioned.
[collections] Support parametized classes with commons.collections.
---
Key: COLLECTIONS-110
URL: http://issues.apache.org/jira/browse/COLLECTIONS-110
Project: Commons Collections
Type: Bug
Environment: Operating System: other
Platform: Other
Reporter: Colbert Philippe
It's time to create a parallel version of commons.collections to support
parametized classes of each container class and abstract class. It's not
that
hard. There is a 23 PDF document on Sun Java website describing in detail
how
it should be done and what to watch out for.
I already converted a few classes from commons.collection privately for my
own
needs. Once you get the hang of it, it's a rather quick process.
I am even willing to volunteer my time to do some more but I need the
collaboration of some of the original programmers to watch over things.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-110) [collections] Support parametized classes with commons.collections.
[ http://issues.apache.org/jira/browse/COLLECTIONS-110?page=comments#action_12413908 ] Sergei Ivanov commented on COLLECTIONS-110: --- [cross-posted from Bugzilla] --- Additional Comment #7 From Colbert Philippe 2006-05-23 04:56 [reply] --- Offense not taken. Ok..ok..if Sun implemented it that way. I won't argue. I was wrong. I want to go back to my original goal: To have two consolidated commons.collections version Java 1.4.2 version Java 1.5. Why isn't commons.collections15 not a Jakarta project? Jakarta commons.collections is being updated but I am not sure that commons.collections15 is in synch with it. Why aren't these two projects consolidated? [collections] Support parametized classes with commons.collections. --- Key: COLLECTIONS-110 URL: http://issues.apache.org/jira/browse/COLLECTIONS-110 Project: Commons Collections Type: Bug Environment: Operating System: other Platform: Other Reporter: Colbert Philippe It's time to create a parallel version of commons.collections to support parametized classes of each container class and abstract class. It's not that hard. There is a 23 PDF document on Sun Java website describing in detail how it should be done and what to watch out for. I already converted a few classes from commons.collection privately for my own needs. Once you get the hang of it, it's a rather quick process. I am even willing to volunteer my time to do some more but I need the collaboration of some of the original programmers to watch over things. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-110) [collections] Support parametized classes with commons.collections.
[
http://issues.apache.org/jira/browse/COLLECTIONS-110?page=comments#action_12413923
]
Sergei Ivanov commented on COLLECTIONS-110:
---
Dear Colbert
Apparently issue tracking for Commons Collections has been migrated to JIRA
recently, so I had to copy our latest discussion postings here.
I checked out collections15 from SourceForge CVS and had a closer look at the
code. Here are my observations:
1. It apparently started as a separate project, and has never been endorsed by
ASF
2. The author(s) repackaged many classes (especially functors). This is very
bad, because it makes synchronisation with the baseline extremely complicated.
The project seems to be stalled and based on a dated stable release of
collections.
3. The overall quality of generification is rather good (the author(s)
obviously studied the aforementioned tutorial), but could be better.
I would really love to hear a voice of ASF committers (James?). Without any
active support from Jakarta members the generification project is doomed.
IMO, if this project is to be started, it should be placed into Jakarta
incubator and follow the normal evolution path. I have also got some
generified collections code that I'd be happy to share.
Another issue raised is: which version is to become the main branch. Having
worked in the investment banking industry for the last 4 years, I can say from
my experience that there is a huge number of legacy projects there, many of
which are still rinning on JDK 1.3. And an upgrade to a newer version of the
JDK carries with it a significant element of risk (and potential losses may
amount to millions). And there are many other long-running projects that will
require at least JDK 1.3 compatibility for years to come. Having said that, I
think the current version of collections should still be considered as the
base, and collections-1.5 codebase should be branched off it and it should
absord all changes made later on the main branch.
On the other hand, collections-1.5 may get rid of deprecated classes right at
the start. We can also use the other niceties of java 5, like varargs and
foreach, e.g.:
public AllPredicate(Predicate... predicates) {}
I am ready to contribute to this project if there is any interest from the
community.
[collections] Support parametized classes with commons.collections.
---
Key: COLLECTIONS-110
URL: http://issues.apache.org/jira/browse/COLLECTIONS-110
Project: Commons Collections
Type: Bug
Environment: Operating System: other
Platform: Other
Reporter: Colbert Philippe
It's time to create a parallel version of commons.collections to support
parametized classes of each container class and abstract class. It's not
that
hard. There is a 23 PDF document on Sun Java website describing in detail
how
it should be done and what to watch out for.
I already converted a few classes from commons.collection privately for my
own
needs. Once you get the hang of it, it's a rather quick process.
I am even willing to volunteer my time to do some more but I need the
collaboration of some of the original programmers to watch over things.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
