returning array v genric collection

[VisionSet]

public String[] getMyStrings();
public List<String> getMyStrings();

Which is better now we have generics?

Lets assume we don't have any overhead with converting within the method if
we had the wrong type - Collection to Array or vice versa.

It seems to me that the latter is usually the way to go, since you can often
go through an App without having to convert to an array at all.

I suppose the former is quicker.
But I'd love to here other convincing arguments.

 

[Daniel Dyer]

public String[] getMyStrings();
public List<String> getMyStrings();

Which is better now we have generics?

Lets assume we don't have any overhead with converting within the method
if
we had the wrong type - Collection to Array or vice versa.

It seems to me that the latter is usually the way to go, since you can
often
go through an App without having to convert to an array at all.

I suppose the former is quicker.
But I'd love to here other convincing arguments.

Pre-1.5 I would have favoured the array because it is explicit about
types. However, now I think the list is better because you still get the
typing but can switch between different list implementations (e.g.
ArrayList vs. LinkedList) without having to change any of the public API.

Dan.

 

[Oliver Wong]

public String[] getMyStrings();
public List<String> getMyStrings();

Which is better now we have generics?

Lets assume we don't have any overhead with converting within the method
if
we had the wrong type - Collection to Array or vice versa.

It seems to me that the latter is usually the way to go, since you can
often
go through an App without having to convert to an array at all.

I suppose the former is quicker.
But I'd love to here other convincing arguments.

If there's zero overhead for converting within a method between
Collection to Array or vice versa, then both solutions are equivalent from
the implementor's point of view, except for a conversion at the end of one
of them. All that matters then is the API and what the client code wants. If
the client code wants an array, give them an array. If they want a
Collection, give them a Collection.

Internally, I'd probably prefer to work with collections, because I
might not know what the size of the result is immediately, so I don't know
what size array to allocate.

Thus, if the client doesn't care whether it's an array or a collection
that they receive on the other end (e.g. because they're going to use "for
(element : collection)" style iteration anyway), then I'd just return a
collection, to avoid the overhead of converting to array.

- Oliver

 

[VisionSet]

e.g. because they're going to use "for (element : collection)" style

iteration anyway>

That construct is overloaded for array types also.

Just wanted to make sure there wasn't a good reason to stick with arrays.
Having not seen so much less 1.5 code than what went before, it just seems a
bit odd passing around Collections.

 

[Oliver Wong]

iteration anyway>

That construct is overloaded for array types also.

Yes. Hence the "because", meaning that "the fact that this construct is
overloaded" is the cause of "the client code doesn't care whether it's an
array or a collection
that they receive on the other end".

Just wanted to make sure there wasn't a good reason to stick with arrays.
Having not seen so much less 1.5 code than what went before, it just seems
a
bit odd passing around Collections.

If you don't want the client code to resize the return value, using an
array might be a good idea. If you want the return value to be completely
immutable though, it's probably better to return your own implementation of
Collection which doesn't implement any of the add/remove or other mutator
methods.

Which one is better to use, like any design choice, depends on the
context.

- Oliver

 

[Thomas Hawtin]

public String[] getMyStrings();
public List<String> getMyStrings();

Which is better now we have generics?

Lets assume we don't have any overhead with converting within the method if
we had the wrong type - Collection to Array or vice versa.

It seems to me that the latter is usually the way to go, since you can often
go through an App without having to convert to an array at all.

I'd go with the latter.

Arrays behave awkwardly with generics. For instance, you couldn't return
Map<String,String>[].

You can parameterize the type.

General methods that could apply to either arrays or lists, only have to
apply to lists if you avoid arrays.

You get a choice of implementation.

You remain consistent with methods that return live collections (i.e.
update with the object you get it from, like Map.entrySet).

Tom Hawtin

 

[Thomas G. Marshall]

Oliver Wong coughed up:

....[rip]...

If you want the return value to be completely
immutable though, it's probably better to return your own implementation
of
Collection which doesn't implement any of the add/remove or other mutator
methods.

Tough to do cleanly, since the mutators are part of the Collection
interface. You could always break the OO rule and implement them, but have
them punt or do nothing. Squashing part of a superclass's (or java
interface's) interface is a no-no, but done from time to time anyway.

....[rip]...

 

[Thomas G. Marshall]

Oliver Wong coughed up:

public String[] getMyStrings();
public List<String> getMyStrings();

Which is better now we have generics?

Lets assume we don't have any overhead with converting within the method
if
we had the wrong type - Collection to Array or vice versa.

It seems to me that the latter is usually the way to go, since you can
often
go through an App without having to convert to an array at all.

I suppose the former is quicker.
But I'd love to here other convincing arguments.

If there's zero overhead for converting within a method between
Collection to Array or vice versa, then both solutions are equivalent from
the implementor's point of view, except for a conversion at the end of one
of them.

So long as the implementer keeps firmly in mind that the arraylist is
/itself/ implemented with an array. So there's always at least a smidgeon
of overhead.

 

[=?ISO-8859-1?Q?Asbj=F8rn?= L. Johansen]

Oliver Wong coughed up:

Tough to do cleanly, since the mutators are part of the Collection
interface. You could always break the OO rule and implement them, but have
them punt or do nothing. Squashing part of a superclass's (or java
interface's) interface is a no-no, but done from time to time anyway.

These operations are marked as optional in the API, and if you read the
docs you will see that a Collection can throw an
UnsupportedOperationException from these methods.

 

[Thomas G. Marshall]

Asbjørn L. Johansen coughed up:

These operations are marked as optional in the API, and if you read
the docs you will see that a Collection can throw an
UnsupportedOperationException from these methods.

Fair enough, mea culpa. I had forgotten that entirely, thanks.

 

[Chris Smith]

If you want the return value to be completely
immutable though, it's probably better to return your own implementation of
Collection which doesn't implement any of the add/remove or other mutator
methods.

Eh? Why not use Collections.unmodifiableList(...)?

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Oliver Wong]

Eh? Why not use Collections.unmodifiableList(...)?

'Cause I couldn't find it... While working on some code, I had to return
an unmodifiable list, and I was pretty sure I had seen an API call to do
just that, but I couldn't the call in the JavaDocs so I ended up writing my
own. Anyway, thanks for showing me where it is.

- Oliver

 

[Thomas G. Marshall]

Chris Smith said something like:

Eh? Why not use Collections.unmodifiableList(...)?

Probably because he forgot it......like I did. {embarrassed}