Product / Option implementing Iterable

[Alex Neth-2]

Option already defines the Iterable methods map, foldLeft, etc.  This
is convenient to avoid more verbose pattern massing.

E.g.

def optionalPrintLn(o:Option[Any]) {
  o.map((v) => println(v.toString))
}

If Product (or maybe just Option and possibly the Tuples) implemented
Iterable we could write that:

def optionalPrintLines(i:Iterable[Any]) {
  i.map((v) => println(v.toString))
}

and then we could call:

printLines(List("hello", "world"))
printLines(Some("hello"))
printLines(None)
printLines(Nil)
printLines((1,2,3))

This could be convenient to write more generalized functions.

Overkill?


--
Alex Neth
Liivid, Inc
www.liivid.com
[phone]
[phone]

Ted Turner  - "Sports is like a war without the killing." -
http://www.brainyquote.com/quotes/authors/t/ted_turner.html

[Ismael Juma]

On Fri, 2009-11-06 at 02:48 -0800, Alex Neth wrote:
> printLines(List("hello", "world"))
> printLines(Some("hello"))
> printLines(None)
> printLines(Nil)

These already work. The Option case works because there's an implicit
conversion from Option to Iterable.

> printLines((1,2,3))

This doesn't. I don't know why Product doesn't implement Iterable, but I
suspect it's to allow case classes to implement Iterable where the
iteration is not over the fields. A good example of this is the :: case
class (that inherits from List).

Best,
Ismael

[Randall Schulz]

On Friday November 6 2009, Ismael Juma wrote:
> ...
>
> > printLines((1,2,3))
>
> This doesn't. I don't know why Product doesn't implement Iterable,
> but I suspect it's to allow case classes to implement Iterable where
> the iteration is not over the fields. A good example of this is the
> :: case class (that inherits from List).

Wouldn't the type-heterogeneity of the elements of Product (hence all
case classes, including TupleN) make that infeasible? If it were
Iterable, it would have to iterate over Any, would it not?


> Best,
> Ismael


Randall Schulz

[Ismael Juma]

On Fri, 2009-11-06 at 07:07 -0800, Randall R Schulz wrote:

> On Friday November 6 2009, Ismael Juma wrote:
> > ...
> >
> > > printLines((1,2,3))
> >
> > This doesn't. I don't know why Product doesn't implement Iterable,
> > but I suspect it's to allow case classes to implement Iterable where
> > the iteration is not over the fields. A good example of this is the
> > :: case class (that inherits from List).
>
> Wouldn't the type-heterogeneity of the elements of Product (hence all
> case classes, including TupleN) make that infeasible?

I am not sure what you're claiming to be infeasible. I presented a
reason why making it an Iterable would be problematic.

>  If it were
> Iterable, it would have to iterate over Any, would it not?

It would be an Iterable[Any], yes. As the signature of productElement
shows:

def productElement(n: Int): Any

Best,
Ismael

[Randall Schulz]

On Friday November 6 2009, Ismael Juma wrote:
> On Fri, 2009-11-06 at 07:07 -0800, Randall R Schulz wrote:
> > ...
> >
> > Wouldn't the type-heterogeneity of the elements of Product (hence
> > all case classes, including TupleN) make that infeasible?
>
> I am not sure what you're claiming to be infeasible. I presented a
> reason why making it an Iterable would be problematic.

OK, not infeasible, unuseful. And I was responding to your saying
"I don't know why Product doesn't implement Iterable." It seems that
Iterable across all Product would just not serve any good purpose
(entirely apart from the usurpation of List's defining it as something
other than iteration over elements).


> ...
>
> Best,
> Ismael


Randall Schulz

[Ismael Juma]

On Fri, 2009-11-06 at 07:34 -0800, Randall R Schulz wrote:
> On Friday November 6 2009, Ismael Juma wrote:
> > I am not sure what you're claiming to be infeasible. I presented a
> > reason why making it an Iterable would be problematic.
>
> OK, not infeasible, unuseful. And I was responding to your saying
> "I don't know why Product doesn't implement Iterable." It seems that
> Iterable across all Product would just not serve any good purpose
> (entirely apart from the usurpation of List's defining it as something
> other than iteration over elements).

When I said "I don't know" is not because I think it's a good idea, it's
because I have not read any official explanation. Having said that, I
would not classify it as unuseful, just of limited usefulness.

The fact that it limits case classes as I described earlier is a bigger
issue in my opinion.

Best,
Ismael