Post #168,414
8/10/04 9:03:02 AM
8/10/04 9:14:32 AM
|
Java collections vs arrays
I had a disagreement with a co-worker today whether a method should return an array or a collection. I preferred a Collection because it encapsulates the implementation, the Collection could be implemented as a LinkedList, an ArrayList or some othe Collection and if needed I could change the implementation of the Collection without changing the interface. In addition, it seems like the overall trend in Java is moving to Collections and away from arrays. An array on the other hand exposes the implementation and makes it part of the interface. I cannot change the implementation to something more suitable without changing the API. The advantage to using an array is that there is no need to cast the Objects, the array has a distinct type (this will be remedied in 1.5). In addition arrays are more efficient.
What is annoying about Java is that Arrays are these quasi special Objects that don't really fit into the rest of Java. They have their own operators their own weird classes etc. are not subclassable, etc. It would have been so much better if an array in Java was just a fixed size list, of course they couldn't do that because they needed to support arrays of primitive types. These kinds of these things make me pine for Smalltalk.
Edited by bluke
Aug. 10, 2004, 09:14:32 AM EDT
|
Post #168,422
8/10/04 9:24:34 AM
|
Arrays annoy me to no end.
No, I do not wish to write a full-fledged for loop just to iterate the bloody thing.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #168,429
8/10/04 9:53:44 AM
|
How is an Iterator much better?
You still need to write something like
Iterator itr = col.iterator;
while(itr.hasNext()) {
...do something
}
Lately I have seen a lot of the following where a for loop is used to iterate over a Collection, in fact, this is the code that Intellij generates to do that. I personally much prefer the while loop.
for (Iterator iterator = collection.iterator(); iterator.hasNext();) {
Object o = (Object) iterator.next();
\t\t\t
\t\t}
besides in a good IDE like Intellij it writes the for loop for you
|
Post #168,431
8/10/04 9:57:44 AM
|
Re: How is an Iterator much better?
Personal preference, I guess. I use the for style of iteration.
I prefer Python's "for foo in bar:" syntax over everything else. :-)
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #168,434
8/10/04 10:03:27 AM
|
That is coming to Java in 1.5
you will ge able to write something like this:
List<String> names = new ArrayList<String>();
...
for (String name: names) {
... do something
}
|
Post #168,516
8/10/04 6:59:14 PM
|
Oh, joy -- looks like the STL.
They won't rest until they've remade Java back into C++.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #168,517
8/10/04 7:38:36 PM
|
Dang. Now I've got a WSOD.
while milk:\n screen.append(milk.pop()) "Despite the seemingly endless necessity for doing
so, it's actually not possible to reverse-engineer intended invariants
from staring at thousands of lines of code (not in C, and not in
Python code either)." Tim Peters on python-dev
|
Post #168,519
8/10/04 7:56:50 PM
|
ICMLPRD
Dang. Now I've got a WSOD. while milk:\n screen.append(milk.pop())
WANTED: Precognitive Telepath for adventuring Partnership. You know where to apply.
|
Post #168,521
8/10/04 7:57:53 PM
|
ICMLPRD (new thread)
Created as new thread #168520 titled [link|/forums/render/content/show?contentid=168520|ICMLPRD]
WANTED: Precognitive Telepath for adventuring Partnership. You know where to apply.
|
Post #168,567
8/11/04 3:40:15 AM
|
It's not so bad
Most people will just use it to define collections of a given type.
Unfortunately they are very conservative and what they did is a bandaid. It is basically compiler magic, the generic type is erased and the compiler inserts the casts. In addition they came up with another bandaid for the primitive type problem, autoboxing, which is quite problematic. It is interesting to note that even the spec leads have come around to teh view that primitive types are an issue.
|
Post #168,481
8/10/04 2:24:31 PM
|
Re: Java collections vs arrays
In general, my experience has been that general APIs should return Collection types, not arrays. I agree with your perspective that arrays tend to provide too much of an internal representation, and lack flexibility.
However, I also prefer not to use java.util.Collection explicitly. I prefer using either List or Set (depending upon the way the method works). Obviously, in some situations, java.util.Collection is more appropriate. However, by specifying List or Set, it gives the user of the API more information about the organization of the data being returned, which is useful to the caller (such as whether there are duplicates, whether they can get direct access to an index, etc.). What irritates me is taking that too far and returning a Vector or Hashtable (usually done by programmers who aren't familiar with the collection framework).
The other concern with returning collections, though, is the common mistake (again, this is referring to more general APIs, and not closely tied code) of returning an internal collection (allowing the caller to mess around with the internals of a class outside of its context). This gets done with arrays, as well, though, so it's not necessarily exclusive to collections (I just see it done more often in those situations). Part of that may be the perception that an array copy is fast (i.e. it gets handled like a memcopy), so returning a copied array is quick (even though most collection implementations use internal arrays and use the same copy mechanism in their toArray() calls).
Anyway, I agree with you (though, that's without looking at the particular example). The speed savings are generally not worth the developer time, etc. to pay the price of a poor interface.
Dan
|
