Re: New collections library: methods that take or return only iterators

2009/5/15 martin odersky :
> On Fri, May 15, 2009 at 3:00 PM, David MacIver wrote:
>> Actually, a quick thought:
>>
>> Iterator[T] could extend Traversable[T] but not Iterable[T].
>
> Only if it saved all iterated elements on each foreach. I believe the
> contract for Traversable should be that foreach can be called multiple
> times.

I don't see why. I mean, I agree there are clear use cases for things
which can be traversed repeatably, but the vast majority of cases
where the collections API defines a method that accepts would work
verbatim with an Iterator as well. So not providing a common contract
for Iterator and Iterable is a recipe for massive code duplication.

2009/5/15 martin odersky :
> On Fri, May 15, 2009 at 5:02 PM, David MacIver wrote:
>> 2009/5/15 martin odersky :
>>> On Fri, May 15, 2009 at 3:00 PM, David MacIver wrote:
>>>> Actually, a quick thought:
>>>>
>>>> Iterator[T] could extend Traversable[T] but not Iterable[T].
>>>
>>> Only if it saved all iterated elements on each foreach. I believe the
>>> contract for Traversable should be that foreach can be called multiple
>>> times.
>>
>> I don't see why.
>
> For instance, Traversable has a size method. Anyone calling this on an Iterator
> would render the Iterator useless afterwards. Same holds for take, drop,
> and most other methods of Traversable.

size is problematic, granted. take, drop and most other methods on
Traversable have fairly well defined behaviour on Iterators, so if
that's all you need the Iterator for then it doesn't seem problematic
that the iterator isn't useful afterwards. :-)

>> I mean, I agree there are clear use cases for things
>> which can be traversed repeatably, but the vast majority of cases
>> where the collections API defines a method that accepts would work
>> verbatim with an Iterator as well. So not providing a common contract
>> for Iterator and Iterable is a recipe for massive code duplication.
>>
> I think the current solution which only overloads ++ works fine in
> practice.

Why is ++ special here? If we're not going to overload in general then
we shouldn't overload for one particular example.

> I never needed to pass Iterators for Traversables anywhere
> else. And if you need to,
> Iterator#toStream is your friend :-)

Fair enough.

On Fri, May 15, 2009 at 3:00 PM, David MacIver wrote:
> Actually, a quick thought:
>
> Iterator[T] could extend Traversable[T] but not Iterable[T].

Only if it saved all iterated elements on each foreach. I believe the
contract for Traversable should be that foreach can be called multiple
times.

On Fri, May 15, 2009 at 5:02 PM, David MacIver wrote:
> 2009/5/15 martin odersky :
>> On Fri, May 15, 2009 at 3:00 PM, David MacIver wrote:
>>> Actually, a quick thought:
>>>
>>> Iterator[T] could extend Traversable[T] but not Iterable[T].
>>
>> Only if it saved all iterated elements on each foreach. I believe the
>> contract for Traversable should be that foreach can be called multiple
>> times.
>
> I don't see why.

For instance, Traversable has a size method. Anyone calling this on an Iterator
would render the Iterator useless afterwards. Same holds for take, drop,
and most other methods of Traversable.

> I mean, I agree there are clear use cases for things
> which can be traversed repeatably, but the vast majority of cases
> where the collections API defines a method that accepts would work
> verbatim with an Iterator as well. So not providing a common contract
> for Iterator and Iterable is a recipe for massive code duplication.
>
I think the current solution which only overloads ++ works fine in
practice. I never needed to pass Iterators for Traversables anywhere
else. And if you need to,
Iterator#toStream is your friend :-)

Cheers