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 Iterator, and if it should
have been List, or Collection, etc.
In looking at the code, it doesn't appear to have been much rhyme or
reason to when we returned Iterators or even arrays.
For the methods that currently return Iterators, my point is that the
big step is agreeing to return Iterables instead (switching from
Iterators to a factory for Iterators). Once you decide to return
Iterables for immutable objects, then you might as well return the
correct Collection classes--Collection, List, Set as returning these
classes places no additional api burden on the implementor as I believe
that even in the worst case where the implementor only had an Iterable
and not the actual Collection class in question, a simple adapter could
be written to convert an Iterable into the appropriate unmodifiable
Collection class.
-- Blake Sullivan
I'm not thrilled with exposing List if you think that
you might someday want it to be a Set - Collection
is safer in that regard.
-- Adam
On 4/9/07, Blake Sullivan <[EMAIL PROTECTED]> wrote:
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 is limiting the
implementations choices severely enough that it outweighs the
convenience of using a Collection class?
-- Blake Sullivan
Jeanne Waldman wrote:
> three out of six
>
> -------- Original Message --------
> Subject: Re: return an Iterator vs a List
> Date: Wed, 4 Apr 2007 15:42:17 -0700
> From: Adam Winer <[EMAIL PROTECTED]>
> Reply-To: adffaces-dev@incubator.apache.org
> To: adffaces-dev@incubator.apache.org
> References:
> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
>
>
>
> If the only reason is to enable the fun new "for" syntax,
> then we should change the type from Iterator to Iterable,
> instead of List. List is a much larger contract.
>
> -- Adam
>
>
> On 3/28/07, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
>> Hi there,
>> I'm in the Skinning StyleNode code and I see that the 'get' methods
>> return Iterators
>> from the good ol' days.
>> It seems to me that it is better if they just return Lists so the
code
>> that iterates over
>> the values is cleaner using 5.0's for(String foo : yyy) construct.
>> Does anyone see why I wouldn't want these to return List instead of
>> Iterator?
>>
>> Here's a code snippet. Thanks, Jeanne
>> --
>>
>> public Iterator<IncludePropertyNode> getIncludedProperties()
>> {
>> if(_includedProperties == null)
>> {
>> List<IncludePropertyNode> list = Collections.emptyList();
>> return list.iterator();
>> }
>> else
>> return (Arrays.asList(_includedProperties)).iterator();
>> }
>>
>> /**
>> * Gets the properties specified by this node's parent that
should be
>> * ignored. This method will return an empty iterator if
>> * [EMAIL PROTECTED] #isInhibitingAll()} returns <code>true</code>
>> *
>> * @return an iterator over the properties that should be
ignored, an
>> * empty iterator if all properties should be.
>> */
>> public Iterator<String> getInhibitedProperties()
>> {
>> if(_inhibitedProperties == null)
>> {
>> List<String> list = Collections.emptyList();
>> return list.iterator();
>> }
>> else
>> {
>> return _inhibitedProperties.iterator();
>> }
>> }
>>
>