This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Exposing Scala containers to non-Scala consumers as java.lang.Iterable

7 replies
ewilligers
Joined: 2008-08-20,
User offline. Last seen 3 years 17 weeks ago.

This was discussed last year but I notice it isn't currently implemented
in trunk. Original conversation:
http://www.nabble.com/How-to-set-the-scale-for-scala.BigDecimal%27s---me...
(BTW, I've come across another use case - accessing Scala from Clojure,
which makes heavy use of Iterable.)

Is the subtyping from Java still planned? There would seem to be two
implementation options - one simple, one a compiler change giving a more
general interoperability enhancement.

Option 1.

Change
trait Iterable[+A] extends ...
to
trait Iterable[+A] extends ... with java.lang.Iterable[Any]

In Iterable implement the method

def iterator(): Iterator[A] = elements()

Change
trait Iterator[+A]
to
trait Iterator[+A] extends java.util.Iterator[Any]

In Iterator implement the method

def remove() {
throw new UnsupportedOperationException()
}

Java users would be free to cast from java.lang.Iterable[Any] to
java.lang.Iterable[A], similarly for Iterator.

Option 2.

Permit inheritance like

// Java
interface Co[T] {
public T f();
}

interface Contra[U] {
public void g(U u);
}

// Scala
trait X[+T, -U] extends Co[T] with Contra[U] {}

i.e. Change the Scala compiler and language spec to allow generic Java
interfaces - not classes, not Scala traits - to be inherited from as if
they were declared covariant (or contravariant), provided the interface
only uses the type parameter in the covariant (or contravariant) position.

Then we can improve on the library changes in Option 1 by extending
java.lang.Iterable[A] and java.util.Iterator[A]

odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: Exposing Scala containers to non-Scala consumers as java.l

On Fri, Jun 12, 2009 at 5:14 PM, Eric Willigers wrote:
> This was discussed last year but I notice it isn't currently implemented in
> trunk. Original conversation:
> http://www.nabble.com/How-to-set-the-scale-for-scala.BigDecimal%27s---me...
> (BTW, I've come across another use case - accessing Scala from Clojure,
> which makes heavy use of Iterable.)
>

I just reread that discussion. At the time there was no consensus for
making the change. We since removed one of the objections: Scala
iterables have an iterator method just like Java's do. The other
objection, that we'd then inherit a mostly non-functional remove
method from Iterator still stands. Opinions?

Cheers

Chris Twiner
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Exposing Scala containers to non-Scala consumers as java.l

On Fri, Jun 12, 2009 at 6:50 PM, martin odersky wrote:
> On Fri, Jun 12, 2009 at 5:14 PM, Eric Willigers wrote:
>> This was discussed last year but I notice it isn't currently implemented in
>> trunk. Original conversation:
>> http://www.nabble.com/How-to-set-the-scale-for-scala.BigDecimal%27s---me...
>> (BTW, I've come across another use case - accessing Scala from Clojure,
>> which makes heavy use of Iterable.)
>>
>
> I just reread that discussion. At the time there was no consensus for
> making the change. We since removed one of the objections: Scala
> iterables have an iterator method just like Java's do. The other
> objection, that we'd then inherit a mostly non-functional remove
> method from Iterator still stands. Opinions?
>

Standard implicits, when in scala, from scala's Iterable to java's
Iterable. Static helper functions for use in java/other jvm langs. I
personally don't find the need for "seamless" interoperability at such
a cost when a simple function call and wrappers will do.

The only thing for me is that they should be standard, now that 1.5jdk
is standard in 2.8, I am sure most projects have copies of such
functions, it'd be great to just have one copy.

Arthur Peters
Joined: 2009-01-09,
User offline. Last seen 42 years 45 weeks ago.
Re: Exposing Scala containers to non-Scala consumers as java.l

Iterator.remove() is optional [1]. So the default implementation could
be to throw UnsupportedOperationException. Then mutable collections
(which are already not really functional) can really implement it.

Obviously that doesn't solve the aesthetic issue of having a
non-implemented public function in a bunch of functional collection
iterators.

-Arthur

[1] http://java.sun.com/javase/6/docs/api/java/util/Iterator.html#remove()

On Fri, Jun 12, 2009 at 12:50 PM, martin odersky wrote:
>
> On Fri, Jun 12, 2009 at 5:14 PM, Eric Willigers wrote:
> > This was discussed last year but I notice it isn't currently implemented in
> > trunk. Original conversation:
> > http://www.nabble.com/How-to-set-the-scale-for-scala.BigDecimal%27s---me...
> > (BTW, I've come across another use case - accessing Scala from Clojure,
> > which makes heavy use of Iterable.)
> >
>
> I just reread that discussion. At the time there was no consensus for
> making the change. We since removed one of the objections: Scala
> iterables have an iterator method just like Java's do. The other
> objection, that we'd then inherit a mostly non-functional remove
> method from Iterator still stands. Opinions?
>
> Cheers
>
>  -- Martin

ewilligers
Joined: 2008-08-20,
User offline. Last seen 3 years 17 weeks ago.
Re: Exposing Scala containers to non-Scala consumers as java.

Arthur Peters wrote:
> Obviously that doesn't solve the aesthetic issue of having a
> non-implemented public function in a bunch of functional collection
> iterators.

Some(1).wait() compiles but makes no sense.

Such aesthetic issues are the price of embracing the platform - a Scala
object instance is a Java object instance.

I'm suggesting that Iterable is similarly fundamental and that Groovy,
Java, JRuby, Clojure shouldn't have to jump through "implicit" hoops to
use Scala iterables.

Paul Chiusano
Joined: 2009-01-01,
User offline. Last seen 42 years 45 weeks ago.
Re: Exposing Scala containers to non-Scala consumers as java.l
I don't really like the idea of any aspect of Scala collections extending or implementing or implementing java interfaces. The java collections api is IMO poorly designed, not worth mimicking, and if you want interoperability, then as Chris says it's trivial to write some wrappers that covert between Scala and Java equivalents. I wouldn't mind though if scala's standard library had scala to java conversion functions - this has been discussed on this list in the past - I just don't want scala collections to BE java collections.
Paul

On Fri, Jun 12, 2009 at 1:13 PM, Chris Twiner <chris [dot] twiner [at] gmail [dot] com> wrote:
On Fri, Jun 12, 2009 at 6:50 PM, martin odersky<martin [dot] odersky [at] epfl [dot] ch> wrote:
> On Fri, Jun 12, 2009 at 5:14 PM, Eric Willigers<ewilligers [at] gmail [dot] com> wrote:
>> This was discussed last year but I notice it isn't currently implemented in
>> trunk. Original conversation:
>> http://www.nabble.com/How-to-set-the-scale-for-scala.BigDecimal%27s---method--td20719942.html#a20732644
>> (BTW, I've come across another use case - accessing Scala from Clojure,
>> which makes heavy use of Iterable.)
>>
>
> I just reread that discussion. At the time there was no consensus for
> making the change. We since removed one of the objections: Scala
> iterables have an iterator method just like Java's do. The other
> objection, that we'd then inherit a mostly non-functional remove
> method from Iterator still stands. Opinions?
>

Standard implicits, when in scala, from scala's Iterable to java's
Iterable. Static helper functions for use in java/other jvm langs. I
personally don't find the need for "seamless" interoperability at such
a cost when a simple function call and wrappers will do.

The only thing for me is that they should be standard, now that 1.5jdk
is standard in 2.8, I am sure most projects have copies of such
functions, it'd be great to just have one copy.

Ricky Clarkson
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: Exposing Scala containers to non-Scala consumers as java.l

Then you deliberately make Scala collections useless for Java code. I
don't know why you'd do that.

I'd rather not have to notice that Scala collections are Java
collections when writing in Scala. Let's say that scala.Iterable
would subtype java.util.Iterable on the JVM, and
System.Collections.Generic.IEnumerable on the CLR. But we wouldn't
have to see the Java/.NET specific APIs, only what Scala defines.

I await Paul or David's patient explanation of why this wouldn't work.

2009/6/15 Paul Chiusano :
> I don't really like the idea of any aspect of Scala collections extending or
> implementing or implementing java interfaces. The java collections api is
> IMO poorly designed, not worth mimicking, and if you want interoperability,
> then as Chris says it's trivial to write some wrappers that covert between
> Scala and Java equivalents. I wouldn't mind though if scala's standard
> library had scala to java conversion functions - this has been discussed on
> this list in the past - I just don't want scala collections to BE java
> collections.
> Paul
>
> On Fri, Jun 12, 2009 at 1:13 PM, Chris Twiner
> wrote:
>>
>> On Fri, Jun 12, 2009 at 6:50 PM, martin odersky
>> wrote:
>> > On Fri, Jun 12, 2009 at 5:14 PM, Eric Willigers
>> > wrote:
>> >> This was discussed last year but I notice it isn't currently
>> >> implemented in
>> >> trunk. Original conversation:
>> >>
>> >> http://www.nabble.com/How-to-set-the-scale-for-scala.BigDecimal%27s---me...
>> >> (BTW, I've come across another use case - accessing Scala from Clojure,
>> >> which makes heavy use of Iterable.)
>> >>
>> >
>> > I just reread that discussion. At the time there was no consensus for
>> > making the change. We since removed one of the objections: Scala
>> > iterables have an iterator method just like Java's do. The other
>> > objection, that we'd then inherit a mostly non-functional remove
>> > method from Iterator still stands. Opinions?
>> >
>>
>> Standard implicits, when in scala, from scala's Iterable to java's
>> Iterable. Static helper functions for use in java/other jvm langs. I
>> personally don't find the need for "seamless" interoperability at such
>> a cost when a simple function call and wrappers will do.
>>
>> The only thing for me is that they should be standard, now that 1.5jdk
>> is standard in 2.8, I am sure most projects have copies of such
>> functions, it'd be great to just have one copy.
>
>

Paul Chiusano
Joined: 2009-01-01,
User offline. Last seen 42 years 45 weeks ago.
Re: Exposing Scala containers to non-Scala consumers as java.l
Then you deliberately make Scala collections useless for Java code.  I don't know why you'd do that.

I don't think this makes it useless. I use scala collections all the time in Java code. I use a different api for accessing the data in these collections than what's in java.util.collections, but this isn't a problem. If I want the same interface, I can easily create a wrapper that implements the relevant java interface but is backed by the Scala equivalent. The nice thing here is that Java's silly design errors don't leak into the public API of Scala's collections.
I'd rather not have to notice that Scala collections are Java collections when writing in Scala. I await Paul or David's patient explanation of why this wouldn't work.

Interesting... I can't think of any reason why this wouldn't work offhand and it would be a nice compromise. I think as long as this detail is opaque to Scala code it would be okay. This sounds sort of like how it is is opaque that the boxed representation of Int, Double, etc are mapped to their java.lang equivalents on the JVM.
Paul

On Mon, Jun 15, 2009 at 11:37 AM, Ricky Clarkson <ricky [dot] clarkson [at] gmail [dot] com> wrote:
Then you deliberately make Scala collections useless for Java code.  I
don't know why you'd do that.

I'd rather not have to notice that Scala collections are Java
collections when writing in Scala.  Let's say that scala.Iterable
would subtype java.util.Iterable on the JVM, and
System.Collections.Generic.IEnumerable on the CLR.  But we wouldn't
have to see the Java/.NET specific APIs, only what Scala defines.

I await Paul or David's patient explanation of why this wouldn't work.

2009/6/15 Paul Chiusano <paul [dot] chiusano [at] gmail [dot] com>:
> I don't really like the idea of any aspect of Scala collections extending or
> implementing or implementing java interfaces. The java collections api is
> IMO poorly designed, not worth mimicking, and if you want interoperability,
> then as Chris says it's trivial to write some wrappers that covert between
> Scala and Java equivalents. I wouldn't mind though if scala's standard
> library had scala to java conversion functions - this has been discussed on
> this list in the past - I just don't want scala collections to BE java
> collections.
> Paul
>
> On Fri, Jun 12, 2009 at 1:13 PM, Chris Twiner <chris [dot] twiner [at] gmail [dot] com>
> wrote:
>>
>> On Fri, Jun 12, 2009 at 6:50 PM, martin odersky<martin [dot] odersky [at] epfl [dot] ch>
>> wrote:
>> > On Fri, Jun 12, 2009 at 5:14 PM, Eric Willigers<ewilligers [at] gmail [dot] com>
>> > wrote:
>> >> This was discussed last year but I notice it isn't currently
>> >> implemented in
>> >> trunk. Original conversation:
>> >>
>> >> http://www.nabble.com/How-to-set-the-scale-for-scala.BigDecimal%27s---method--td20719942.html#a20732644
>> >> (BTW, I've come across another use case - accessing Scala from Clojure,
>> >> which makes heavy use of Iterable.)
>> >>
>> >
>> > I just reread that discussion. At the time there was no consensus for
>> > making the change. We since removed one of the objections: Scala
>> > iterables have an iterator method just like Java's do. The other
>> > objection, that we'd then inherit a mostly non-functional remove
>> > method from Iterator still stands. Opinions?
>> >
>>
>> Standard implicits, when in scala, from scala's Iterable to java's
>> Iterable. Static helper functions for use in java/other jvm langs. I
>> personally don't find the need for "seamless" interoperability at such
>> a cost when a simple function call and wrappers will do.
>>
>> The only thing for me is that they should be standard, now that 1.5jdk
>> is standard in 2.8, I am sure most projects have copies of such
>> functions, it'd be great to just have one copy.
>
>

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland