I agree with Blake. We'll get ourselves into trouble is we begin
switching objects around, because if people need the other access
methods they'll do a cast and we'll break them.
Furthermore, if we use the generic Collections (like List, Set, etc.)
then it is more clear as to what constraints
Adam Winer wrote:
I don't think there's that much reason not to return
a List. All I'm saying is that if you had an API
that was Iterator, and your desire was to support
the fun SE 5 "for" construct, then Iterable is the
simplest change. The question then is why the
original API was ever Iterat
I don't think there's that much reason not to return
a List. All I'm saying is that if you had an API
that was Iterator, and your desire was to support
the fun SE 5 "for" construct, then Iterable is the
simplest change. The question then is why the
original API was ever Iterator, and if it shoul
Adam,
Actually the reason for the switch to List versus Iterable would be for
general convenience of developers consuming the api (with efficiency a
much smaller issue).
Which methods on java.util.List do you think are providing too broad of
a contract? Do you believe that returning a List