Some comments inline. I'll use the voting syntax, in an effort to be concise, not formal.
On Sat, 18 Oct 2003, Stephen Colebourne wrote: > I would like to propose the following changes for the primitives code as we > establish it: > > New interface Collectable (better names?). Superinterface of XxxCollection > and XxxMap > - size() > - clear() > - isEmpty() > There are so many times that I've needed a shared interface between > Collection and Map +0, I've never had that need, but it sounds reasonable to me. > - clone() > Fix a JDK error I'm +1 to making the implementations cloneable, -1 to requiring this at the interface level (e.g., I'm opposed to IntCollection extends Cloneable). Among other problems, this will be difficult to enforce at the adapter level. > - isModifiable() > This would be nice to know I'm +0 to a Modifiable interface, but -1 to an isModifiable method. It would be impossible to reliably implement isModifiable at the adapter level. Also, I'm not sure that Modifiable is the proper resolution. Some types may allow "set" or "remove" but not "add", etc. (SingletonIterator is one such example in the object case). Is such a collection modifiable? > - optimize() > For example, implemented as a trimToSize +1 > New interface PCollection (or PrimitiveCollection): > - toCollection() > It should be really easy to get a JDK collection from a [primitives] one. <Type>CollectionCollection.wrap(my<type>collection) does this already. I'd be OK with adding a convenience method somewhere, though I'm not sure PrimitiveCollection is the right place for it. (Perhaps PrimitiveCollections.toCollection(<Type>Collection): Collection?) > New methods on IntCollection (et al): > - addAll(int[]) > - removeAll(int[]) > - containsAll(int[]) > Primitive handling is often done with arrays at present, so provide good > integration -0, I'd prefer simply providing an array-to-primitive collection (or list) adapter, which would then support all these methods and more. > - toArray(int[], int) > Offers a way to get the primitives into a specific index in an existing > array. This is functionally similar to addAll(int,IntCollection)? Then as above, I'd prefer the wrapper approach, or at least the signature addAll(int,int[]) > New interface PList (or PrimitiveList): > - toList() > It should be really easy to get a JDK collection from a [primitives] one. As above (for PCollection.toCollection). > - removeRange(int, int) > Although possible via subList(), this is quicker and more obvious -0, I'm not sure that's quicker, and the "sublist as range operation" stuff is pretty well established, but we could do worse. > New methods on IntList (et al): > - first() > - last() > Because list.get(list.size() - 1) is a pain +1 > - indexOf(int, int) > - lastIndexOf(int, int) > Completes the set of index methods as per String +1 As long as a reasonable implementation can be made within the adapters. > - addAll(int, int[]) > Primitive handling is often done with arrays at present, so provide good > integration I'm not sure I understand the relationship between this and toArray(int[],int) as above. Do you mean for toArray(int[],int) to return a new array with the elements of the collection inserted? That sounds useful I guess, but I'd stick it in some convenience method and not the core interface. Again I think an adapter between a primitive array and a primitive collection might be most helpful here. > > IMO, these represent a balanced extension to the JDK collection design to > fit well in the primitives problem space. Opinions welcome. > > Stephen > > -- - Rod <http://radio.weblogs.com/0122027/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
