Additions to the Collections API

Hi,

Just had an idea for some useful additional methods for the Collection interface. Are such things in the pipeline? If not, is there a way to formally request them?

publicinterface Collection<E>extends Iterable<E>{

publicboolean addAll(E... o);

publicboolean addAll(int index, E... o);

}

publicclass ArrayList<E>implements List<E>{

public ArrayList(E... o){

super();

addAll(o);

}

}

And probably others of a like nature, using the new "..." notation for adding as many things as you want to a method call.

Allows you to instantiate a list where you know the members in much the same way you would an array - instead of

String[] letters =new String[]{"A","B","C"};

you would have

List<String> letters =new ArrayList<String>("A","B","C");

I've created my own subclass of ArrayList to let me do the constructor, but it looks to me like a no-lose addition to the API - can't break any existing code.

[1917 byte] By [Mahoney266a] at [2007-10-3 2:58:17]
# 1
The proper way to request features (or report bugs) is through the bug database: http://bugs.sun.com/bugdatabase/BTW, do you know about Arrays.asList(...)?
Herko_ter_Horsta at 2007-7-14 20:47:44 > top of Java-index,Core,Core APIs...
# 2

Yes, but I think these versions are syntactically nicer than

List<String> list = Arrays.asList(new String[] {"A", "B", "C"});

which looks overly busy and non-intuitive to me.

Thanks for the pointer to where to request such things.

Mahoney266a at 2007-7-14 20:47:44 > top of Java-index,Core,Core APIs...
# 3
Adding methods to standard interfaces is a fairly big deal. You're unlikely to get them unless there's a significant functional (not just syntactic) advantage to the change.If you disagree, raise an RFE.
dcmintera at 2007-7-14 20:47:44 > top of Java-index,Core,Core APIs...
# 4
You don't really need these, as you have Arrays.asList(), so you can do e.g. new ArrayList(Arrays.asList(Object,...));
ejpa at 2007-7-14 20:47:44 > top of Java-index,Core,Core APIs...
# 5

Something a liitle bit different, pls let me know what you think about it: An ArrayList is an implementation of stack - in c++ there's a std::vector with operation push_back() and pop_back(). There's an add operation, but no pop nor peek, which can be of course build using some crazy index computation but these operation are natural to ArrayList and ery efficient and I think that there should not be omitted.

Maaartina at 2007-7-14 20:47:44 > top of Java-index,Core,Core APIs...
# 6
An ArrayList is an implementation of List actually, not a stack. java.util.Stack does what you want. C++'s vector<> which doubles as a stack is hardly a good API model.
ejpa at 2007-7-14 20:47:44 > top of Java-index,Core,Core APIs...
# 7

An ArrayList is a good, simple and staightforward implementation of a stack (having nothing to do with java.util.Stack), except for some trivial missing methods.

java.util.Stack is based on an quite obsolet class - Vector, which was later quite doubled by a better one: ArrayList - this is hardly a good API design, but was necessary. Simply said: Vector is quite useless, it's just a sort of beta version of ArrayList. And so is Stack for the very same reasons (it's synchronized etc.).

Moreover, I do not speak about providing a new class. Just about implementing all the methods making good sense for an existing one.

Maaartina at 2007-7-14 20:47:44 > top of Java-index,Core,Core APIs...
# 8
Then I would still want a new class. It would implement the Queue interface and provide LIFO behaviour.I wouldn't want to repeat the C++ error of making a single vector<> class all things to all men.
ejpa at 2007-7-14 20:47:44 > top of Java-index,Core,Core APIs...
# 9

Implementing a LIFO/Queue is something completelly different, it can't be done with an ArrayList without substantial overhead. There's already a nice implementation of Queue in java.util.ArrayDeque, but this is no simple extension of ArrayList.

If there is a push, why there is no pop?

I see no error in std::vector - IMHO it's perfect: it implements every usable method you can get without additional overhead, and it does not implement anything superfluos or hard to use.

Maaartina at 2007-7-14 20:47:44 > top of Java-index,Core,Core APIs...
# 10
Then we disagree. IMHO C++ has some of the worst-designed class libraries in existence. Prime candidate: iostreams.
ejpa at 2007-7-14 20:47:44 > top of Java-index,Core,Core APIs...
# 11

I can't say much about c++ class libraries in general, and nearly nothing about iostreams, but I know c++ containers quite good and I like them very much.

I do not like java.io at all: I see no reason for the existence of both PrintStream and PrintWriter, I hate "platform's default character encoding" being the default, and I see absolutely no reason for plattform dependent java.io.File (it IS dependent, there're other languages/tools which do not bother me with "/" vs. "\" and other meaningless details).

Maaartina at 2007-7-14 20:47:44 > top of Java-index,Core,Core APIs...
# 12

Then you'd hate iostreams, which are a deadly mixture of input, output, formatting, and a blatant abuse of operator overloading, implemented in an almost completely non-extensible way.

BTW File is platform-independent if you restrict yourself to '/'. It fixes all that nonsense for you.

ejpa at 2007-7-14 20:47:44 > top of Java-index,Core,Core APIs...