incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Blake Sullivan <blake.sulli...@oracle.com>
Subject Re: [Fwd: Re: return an Iterator vs a List]
Date Wed, 11 Apr 2007 21:26:29 GMT
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 <blake.sullivan@oracle.com> 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 <awiner@gmail.com>
>> > Reply-To:     adffaces-dev@incubator.apache.org
>> > To:     adffaces-dev@incubator.apache.org
>> > References:
>> > <71235db40703260457k2902d980n6a7c5b5b98215236@mail.gmail.com>
>> > <71235db40703260753q2921ea4m7eff51554fbff393@mail.gmail.com>
>> > <46098A7A.7000306@oracle.com>
>> > <254acf980703271642s156d9b89lb270e76bf4a2342b@mail.gmail.com>
>> > <f8eab54d0703271646l3e7b67dax8d66a631e4fa0001@mail.gmail.com>
>> > <4609CAC0.9010505@oracle.com>
>> > <f8eab54d0703280924u4890b902gb8423f084ed2cb9b@mail.gmail.com>
>> > <460B259B.2070602@oracle.com>
>> >
>> >
>> >
>> > 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 <jeanne.waldman@oracle.com> 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
>> >>    * {@link #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();
>> >>     }
>> >>   }
>> >>
>> >
>>
>>


Mime
View raw message