 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / November 2005returning array v genric collection
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. -- Mike W > public String[] getMyStrings(); > public List<String> getMyStrings(); [quoted text clipped - 11 lines] > 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.  SignatureDaniel Dyer http://www.dandyer.co.uk > public String[] getMyStrings(); > public List<String> getMyStrings(); [quoted text clipped - 11 lines] > 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 > 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. -- Mike W >> e.g. because they're going to use "for (element : collection)" style > 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 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]... SignatureSometimes life just sucks and then you live. > Oliver Wong coughed up: > > If you want the return value to be completely [quoted text clipped - 7 lines] > 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. -- Asbjrn L. Johansen asbjorjo@stud.ntnu.no Asbjørn L. Johansen coughed up: >> Oliver Wong coughed up: >>> If you want the return value to be completely [quoted text clipped - 12 lines] > 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. > 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(...)? Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation >> If you want the return value to be completely >> immutable though, it's probably better to return your own implementation [quoted text clipped - 3 lines] > > 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 Chris Smith said something like: >> If you want the return value to be completely >> immutable though, it's probably better to return your own implementation [quoted text clipped - 3 lines] > > Eh? Why not use Collections.unmodifiableList(...)? Probably because he forgot it......like I did. {embarrassed} SignatureOnedoctortoanother:"Ifthisismyrectalthermometer,wherethehell'smypen???" Oliver Wong coughed up: >> public String[] getMyStrings(); >> public List<String> getMyStrings(); [quoted text clipped - 16 lines] > 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. > 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 [quoted text clipped - 10 lines] > > - Oliver SignatureSometimes life just sucks and then you live. > public String[] getMyStrings(); > public List<String> getMyStrings(); [quoted text clipped - 6 lines] > 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 SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.