[jira] Commented: (COLLECTIONS-259) TransformerClosure should implement Transformer and allow extension.

[ https://issues.apache.org/jira/browse/COLLECTIONS-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512286 ] Stephen Kestle commented on COLLECTIONS-259: Presumably it's the decoration and continued

[jira] Created: (COLLECTIONS-260) TransformingComparator should have a constructor with just a Transformer

Collections Issue Type: Improvement Components: Comparator Affects Versions: 3.2 Reporter: Stephen Kestle Priority: Minor Fix For: Generics With generics, it's possible to have a constructor like: TransformingComparator(TransformerI, O extends

[jira] Created: (COLLECTIONS-259) TransformerClosure should implement Transformer and allow extension.

Issue Type: Improvement Components: Functor Affects Versions: 3.2 Reporter: Stephen Kestle Priority: Minor Fix For: 3.3, Generics TransformerClosure currently decorates a transformer. However, in the interests of non-verbose code

[jira] Commented: (LANG-326) StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods

[ https://issues.apache.org/jira/browse/LANG-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508943 ] Stephen Kestle commented on LANG-326: - I'm fine with it - at a later point these methods could be re-plumbed

[jira] Commented: (COLLECTIONS-231) Not return the base interface on decorate

[ https://issues.apache.org/jira/browse/COLLECTIONS-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493527 ] Stephen Kestle commented on COLLECTIONS-231: So - fix for generics? Not return the base interface

[jira] Created: (COLLECTIONS-251) Replace getInstance() and decorate() methods with get{ClassName}()

Issue Type: Improvement Components: Bag, BidiMap, Buffer, Collection, Comparator, Core, Functor, Iterator, KeyValue, List, Map, Set Affects Versions: Generics Reporter: Stephen Kestle Fix For: Generics Commons Collections uses the singleton getInstance

Re: [lang] StringUtils startsWith / endsWith methods

, and is encouraged in the javadoc. I'm not sure how to raise a ticket for this, as it probably spans quite a few classes... Henri Yandell wrote: Stephen Kestle had this view of case insensitivity: http://issues.apache.org/jira/browse/LANG-316 Given that I've a strong interest in multiple locales etc, I

Re: [collections] Code offer: TrackingCollection

Please let me know if this is the correct way of submitting code to the project. Better would be to open a ticket (http://issues.apache.org/jira/browse/COLLECTIONS) and submit the files there. Things will get lost on the mailing list. Especially since we all seem to be rather busy...

[jira] Updated: (COLLECTIONS-247) update build to compile with Java 5 and use JUnit 4 and EasyMock in generics branch

[ https://issues.apache.org/jira/browse/COLLECTIONS-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Kestle updated COLLECTIONS-247: --- Description: As requested on [http://wiki.apache.org/jakarta-commons

Re: [collections] additions

- are enhancements to existing classes (as opposed to new classes) still fair game? Yes, IMHO +1 - any objections to me committing in this component? I've started putting stuff on the wiki so that everybody can get a snapshot of all the decisions made, and where people are headed. I'd

Updated wiki

Ok - I've updated the wiki with some information about the project, and a few links to pages that don't yet exist at http://wiki.apache.org/jakarta-commons/Collections/GenericCollections I did want to get a bit further than I have, but it's a start. The next page I'll be working on is

Re: [VOTE] New committer - Stephen Kestle

Wow this is cool - important people voting for me! Just out of interest, are people voting for me because: * of Stephen (C)'s recommendation * of my correspondance (do people actually read all these emails?) * it's the cool thing to do / I seem to be ok Phil Steitz wrote: +1 Phil

Re: [VOTE] New committer - Stephen Kestle

Rahul Akolkar wrote: On 3/21/07, Stephen Kestle [EMAIL PROTECTED] wrote: snip/ Just out of interest, are people voting for me because: * of Stephen (C)'s recommendation * of my correspondance (do people actually read all these emails?) * it's the cool thing to do / I seem

[Collections] Maven help needed

I'm new to maven and apache development, and need some help... I've downloaded Maven 2.0.5, and it isn't able to run the script in the new generics branch of commons collections (http://svn.apache.org/repos/asf/jakarta/commons/proper/collections/branches/collections_jdk5_branch). *

Re: [VOTE] New committer - Stephen Kestle

Does becoming a committer allow me to edit pages such as http://wiki.apache.org/jakarta-commons/Collections? My first action would be to update that so that people can figure out what we're actually doing without trawling mailing lists. Oh, and +1 :) Stephen Colebourne wrote: Stephen has

[collections] VOTE: Rewriting junit tests (Was: Test cases for compilation failures on generifying collections.)

Ok - the problem is that the end of the test is performing a type safety check. Something that the generic parameters will not allow. The collection under test should contain Collections of Strings, not Strings - that's the same as the closure. Therefore it's a compile error to add a string

[jira] Commented: (COLLECTIONS-243) Generic versions of Predicated, Syncronized and Unmodifiable classes

[ https://issues.apache.org/jira/browse/COLLECTIONS-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481971 ] Stephen Kestle commented on COLLECTIONS-243: Remember, Sun's implementation of generics is limited

Re: [collections] VOTE: Rewriting junit tests (Was: Test cases for compilation failures on generifying collections.)

(no GPL or LGPL). Stephen Stephen Kestle wrote: Ok - the problem is that the end of the test is performing a type safety check. Something that the generic parameters will not allow. The collection under test should contain Collections of Strings, not Strings - that's the same

Re: [collections] VOTE: Collections-java5 direction ; notifying collections

Bryce L Nordgren wrote: First, let me understand the proposal. Is a 1.4 compatible version of commons-collections going to continue to be supported simultaneously with the 1.5+ reboot? Your answer above indicates no. I just re-read that: The current version of collections will still be

Re: [collections] VOTE: Collections-java5 direction ; notifying collections

With regards to my -1: rather than rename getInstance methods, I would prefer to remove them and solely rely upon utility methods such as PredicateUtils#truePredicate. I'm potentially fine with that, except I don't want it to be in PredicateUtils - call it Predicates instead. PredicateUtils

[jira] Commented: (COLLECTIONS-244) Proposal to support generic multi-key maps with keys of different types

[ https://issues.apache.org/jira/browse/COLLECTIONS-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480553 ] Stephen Kestle commented on COLLECTIONS-244: 1st: Been there, done that. Ok - do you really want

Re: [collections] VOTE: Collections-java5 direction

James Carman wrote: I +1 all the same stuff, but I'd recommend removing all the getInstance() methods and just provide access via the *Utils classes. I guess, since it's there... but if you were to make a new Predicate of some sort, would you want to update a utility class as well? Java

Re: [collections] VOTE: Collections-java5 direction

Yep - go with CollectionObject rather than Collection?. For those new to generics, if you're using ?, you're 90% likely to be doing something wrong (if you have to use ?, you're really likely to be overcomplicating generics where other tools like covariant return types from multiple classes

[jira] Commented: (COLLECTIONS-243) generic versions of some more classes

[ https://issues.apache.org/jira/browse/COLLECTIONS-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480180 ] Stephen Kestle commented on COLLECTIONS-243: Ok - interesting problem. The contract makes things

Re: [collections] VOTE: Collections-java5 direction

Bryce L Nordgren wrote: Thing 2: (snipped) I don't want the old unchecked behavior. I want checked behavior, commons-collections style. Commons-collections can handle mixed element types, where every element has bounds on its types. Generics do not even contain a way to express this

Re: [collections] VOTE: Collections-java5 direction

Stephen Smith wrote: I've managed to get Eclipse/Subclipse to play nicely and point at the relevant SVN branch - it looks to me as though the interfaces have been genericised, so the implementations and test cases need to be worked on. That said, writing test cases for these changes may be

Re: [collections] VOTE: Collections-java5 direction ; notifying collections

It may be that Java generics adds type safety for some. However, if you're passing collections back and forth between 1.4 code and 1.5/1.6 code, you have all the potential problems of the un-typechecked world _plus_ the false sense of security that you're safe. In short, your library offers

Re: [collections] VOTE: Collections-java5 direction ; notifying collections

Bryce L Nordgren wrote: Stephen Kestle [EMAIL PROTECTED] wrote on 03/12/2007 07:05:21 PM: I'm unsure why people who use Java 5 only should pay a runtime penalty when it isn't needed. If this issue concerns you, use java.utils.Collection.CheckedCollection. Being a C fanatic, I said

Re: [collections] VOTE: Collections-java5 direction ; notifying collections

Apologies for the incomplete sentence... You never pass a Java5 collection to a library written before generics? To give an example close to home: you _never_ use the current commons-collections, in particular the TransformedCollection decorator? I use sf.collections, and never used the

[collections] VOTE: Collections-java5 direction (was: Committing to collections-java5 branch)

Stephen Smith wrote: I think there's merit in simply porting generics to the current Commons Collections 3.2 codebase, but I believe we could get better bang for our buck by discussing how we might reboot Commons Collections. I would suggest a moderately radical approach: 01. Removing all

Re: [collections] VOTE: Collections-java5 direction

Stephen Smith wrote: 05. Re-naming classes and methods. I think that names should be re-evaluated to make sure that they still make sense in the new code. For example, with the singletons we have TruePredicate.getInstance(), but this becomes relatively silly when we have static imports.

[collections] Committing to collections-java5 branch

Hi, I'd like to help work on the generics stuff for collections, as I've benefited in the past from it. Stephen (C), it looks like you're quite busy and could use a hand, so let me know... Cheers Stephen - To unsubscribe,

[jira] Created: (COLLECTIONS-242) Add Equator interface for more powerful collections

Reporter: Stephen Kestle Java has Comparable and Comparator to compare objects, and objects have an equals() method. But there is no interface for when an object has multiple ways of being equal. e.g.: an database object that has a name, code and a value. Equality could be based

[jira] Updated: (COLLECTIONS-242) Add Equator interface for more powerful collections

[ https://issues.apache.org/jira/browse/COLLECTIONS-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Kestle updated COLLECTIONS-242: --- Component/s: Comparator Fix Version/s: Generics Description: Java

[jira] Commented: (LANG-316) Enable CaseInsensitivity in EqualsBuilder and HashCodeBuilder

[ https://issues.apache.org/jira/browse/LANG-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471170 ] Stephen Kestle commented on LANG-316: - No - someone really should read up on Collators etc before jumping

[Collections] Equator interface

)? Is there a Predicate class in Lang? If an Equator is determined to be something worthwhile for the next (generic) version of Collections, I can provide interfaces, default implementations tests etc. Cheers Stephen Kestle

Re: [Collections] Equator interface (methods)

Stephen Colebourne wrote: Stephen Kestle wrote: If an Equator is determined to be something worthwhile for the next (generic) version of Collections, I can provide interfaces, default implementations tests etc. I certainly think that there are multiple ways to to equals checks. In my day

Re: [Collections] Equator interface (and FlexiMap)

Stephen Colebourne wrote: BTW, I favour trying to create a 'FlexiMap' map implementation, which has pluggable hashcode/equals/weakReference/softReference/... So, if anyone wants to give that a go feel free! Stephen In my current code, I have an Equator (equalTo()) method, and a HashEquator

[jira] Commented: (COLLECTIONS-233) Closure is an inaccurate name

[ http://issues.apache.org/jira/browse/COLLECTIONS-233?page=comments#action_12447406 ] Stephen Kestle commented on COLLECTIONS-233: uneccessary code rework is not really so significant if Closure still exists. However, on thinking

Re: [collections] Generics the collection subpackage

If only I had more than +1 vote! Stephen Colebourne wrote: There has been reltively little feedback on these backwards incompatible changes. Do I assume (by lazy consensus) that [collections-generics] will be seriously backwards incompatible? Can I commit changes? Are we agreed on the

[jira] Created: (COLLECTIONS-233) Closure is an inaccurate name

Versions: Generics Reporter: Stephen Kestle The Closure in commons collections is not named well: for non-functional programmers it will induce a what's that?, and for functional programmers it will confuse expectations. From http://en.wikipedia.org/wiki/Closure_(computer_science

Re: [collections] Generics the collection subpackage

Created https://issues.apache.org/jira/browse/COLLECTIONS-233 Stephen Kestle wrote: I shall be opening a ticket for the Closure one in the next while (when I get a chance). Note that Procedure and Function don't actually say anything - they're very broad programming principals. Also note

Re: [collections] Generics the collection subpackage

I shall be opening a ticket for the Closure one in the next while (when I get a chance). Note that Procedure and Function don't actually say anything - they're very broad programming principals. Also note that a Factory may not actually create/generate something (it may already be in the

Re: svn commit: r468106 - /jakarta/commons/proper/collections/branches/collections_jdk5_branch/

Fantastic! Something's happening! At last! Now, can I suggest that a diff/patch be run from collections.sf.net? I reckon about 95% of the changes there are good. Also, where do I open tickets against this new branch? Has that been set up? [EMAIL PROTECTED] wrote: Author: nuttycom

Re: [collections] Generifying Collections

(Ok - how bizarre - I sent this mail yesterday (2 days?), but it went nowhere...) Definitely. It's built to be as api compatible as possible with collections, while upgrading to generics. It's also going through the process of making it easier to use from a generics side of things (doesn't

Re: [collections] Generifying Collections

I for one would like to see the getInstance() methods renamed to getClassName(). With java 5 static importing, it enables concise construction/getting without specifying the class name. It's short, highly readable, and most of the time the generic types can be inferred. It's things like

[jira] Commented: (COLLECTIONS-218) CollectionUtils.select() does not return passed in collection

[ http://issues.apache.org/jira/browse/COLLECTIONS-218?page=comments#action_12422290 ] Stephen Kestle commented on COLLECTIONS-218: Binary compatibility only matters if the type is Serializable right? Is there something I'm

[jira] Commented: (COLLECTIONS-110) Support parametized classes with commons.collections.

[ http://issues.apache.org/jira/browse/COLLECTIONS-110?page=comments#action_12422291 ] Stephen Kestle commented on COLLECTIONS-110: For the new development, I would like to suggest that all Closed, Won't fix bugs could/should be re

[jira] Created: (COLLECTIONS-218) CollectionUtils.select() does not return passed in collection

Type: Improvement Components: Collection Affects Versions: 3.2, 3.1, 3.0, 2.1.1, 2.1, 2.0, 1.0, 3.3, Nightly Builds Reporter: Stephen Kestle collect has the following methods: Collection collect(Collection inputCollection, final Transformer transformer) Collection collect

[jira] Updated: (COLLECTIONS-218) CollectionUtils.select() does not return passed in collection

[ http://issues.apache.org/jira/browse/COLLECTIONS-218?page=all ] Stephen Kestle updated COLLECTIONS-218: --- Attachment: CollectionUtils select return.patch Uploaded patch file for proposed changes. I have also made changes to the two argument

Re: [jira] Commented: (COLLECTIONS-110) [collections] Support parametized classes with commons.collections.

I would suggest possibly projects in the areas of: - functors (functor implementations, utilities and collection decorators) - maps (maps and bidimaps) - collection (collection, list, set, bag) I would add: - base package: All interfaces + Utils (CollectionUtils, MapUtils etc) I also

Re: [collections] Closure is a really bad name

Stephen K Stephen Colebourne wrote: Stephen Kestle wrote: The Closure in commons collections is not named well [snip valid points] So, what to do? I would propose an interface called Processor. It is more intuitive and has many real world examples that can anchor the term so that it makes sense

Closure is a really bad name

standard is Java 5 instead of Java 2) Cheers Stephen Kestle PS. Apologies if this topic has been covered before - I didn't see a search on the mailing list archives... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional