You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-dev@incubator.apache.org by Blake Sullivan <bl...@oracle.com> on 2007/04/09 17:43:50 UTC
Re: [Fwd: Re: return an Iterator vs a List]
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 <aw...@gmail.com>
> Reply-To: adffaces-dev@incubator.apache.org
> To: adffaces-dev@incubator.apache.org
> References:
> <71...@mail.gmail.com>
> <71...@mail.gmail.com>
> <46...@oracle.com>
> <25...@mail.gmail.com>
> <f8...@mail.gmail.com>
> <46...@oracle.com>
> <f8...@mail.gmail.com>
> <46...@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 <je...@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();
>> }
>> }
>>
>
Re: [Fwd: Re: return an Iterator vs a List]
Posted by Scott O'Bryan <da...@gmail.com>.
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 are on returned data. A
set, for instance, cannot have duplicate items, etc. etc. These are
things that we best not violate, contractually, within the API.
Scott
Blake Sullivan wrote:
> 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 <bl...@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 <aw...@gmail.com>
>>> > Reply-To: adffaces-dev@incubator.apache.org
>>> > To: adffaces-dev@incubator.apache.org
>>> > References:
>>> > <71...@mail.gmail.com>
>>> > <71...@mail.gmail.com>
>>> > <46...@oracle.com>
>>> > <25...@mail.gmail.com>
>>> > <f8...@mail.gmail.com>
>>> > <46...@oracle.com>
>>> > <f8...@mail.gmail.com>
>>> > <46...@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 <je...@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();
>>> >> }
>>> >> }
>>> >>
>>> >
>>>
>>>
>
>
Re: [Fwd: Re: return an Iterator vs a List]
Posted by Blake Sullivan <bl...@oracle.com>.
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 <bl...@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 <aw...@gmail.com>
>> > Reply-To: adffaces-dev@incubator.apache.org
>> > To: adffaces-dev@incubator.apache.org
>> > References:
>> > <71...@mail.gmail.com>
>> > <71...@mail.gmail.com>
>> > <46...@oracle.com>
>> > <25...@mail.gmail.com>
>> > <f8...@mail.gmail.com>
>> > <46...@oracle.com>
>> > <f8...@mail.gmail.com>
>> > <46...@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 <je...@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();
>> >> }
>> >> }
>> >>
>> >
>>
>>
Re: [Fwd: Re: return an Iterator vs a List]
Posted by Adam Winer <aw...@gmail.com>.
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.
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 <bl...@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 <aw...@gmail.com>
> > Reply-To: adffaces-dev@incubator.apache.org
> > To: adffaces-dev@incubator.apache.org
> > References:
> > <71...@mail.gmail.com>
> > <71...@mail.gmail.com>
> > <46...@oracle.com>
> > <25...@mail.gmail.com>
> > <f8...@mail.gmail.com>
> > <46...@oracle.com>
> > <f8...@mail.gmail.com>
> > <46...@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 <je...@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();
> >> }
> >> }
> >>
> >
>
>