Quantcast

should Scala import scala.collection.JavaConversions._ by default?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

should Scala import scala.collection.JavaConversions._ by default?

jstrachan
Groovy (and I think Clojure) makes sure that there's no real
difference between java.util collections and the languages collection
API. This really helps working with existing Java APIs; developers
don't have to think if an object is a Java or Groovy List, its just a
List. Scala took a different tack to keep them totally separate and
require explicit developer interaction if you wish to consider
java.util collections to be collections in a Scala like way.

In those cases when you are using Scala to work with existing Java
collection APIs (of which there's a zillion out there), newbies have
to remember to add the "import scala.collection.JavaConversions._"
statement to their source file or REPL shell to be able to use Java
collections in a Scala way. While in the grand scheme of things not a
huge biggie - it is yet one more new thing newbies have to know and
remember.  (Plus some IDEs have a nasty habit of removing this import
when tidying up imports ;-).

In an alternative reality where the Scala library was part of the
JDK's distribution, we'd probably add implicit conversions on
companion objects for java.util.{Iterator, Collection, List, Set} so
that java.util collections always act like scala.collections out of
the box.

So I wondered; should Scala import JavaConversions._ by default? This
would basically be like fixing the JDK, simulating those implicit
conversions being on java.util companion objects?

It may be a small change but think of all those scala developers -
particularly newbies - either in REPLs or in source code having to
remember to cut and paste that line of code so they can iterate
through their java.util collection in some existing
Java/Groovy/Clojure API. IMHO out of the box Scala should know how to
iterate over the java.util collections which are so widely adopted
throughout the Java ecosystem without developers having to remember a
magic import to cut and paste (an import which is pretty hard to find
faced with the scaladoc for the scala library I might add).

I guess a downside to this idea is, what if folks want to use a
different implicit conversion to those supplied in
scala.collection.JavaConversions. I wonder if the compiler could just
have a few fall-back imports which are used if no other mplicit
conversions can be found; e.g. if an implicit conversion cannot be
found, try importing scala.collection.JavaConversions._ (and maybe any
other implicit conversions we add to scala-library for fixing the
JDK). Or have a little list of types (like the collection interfaces
from java.util) which we have default implicit conversions used if the
developer does not specify any? i.e. let users supply alternative
implicit conversions if required - but by default the scala compiler
would just do the right thing for java.util APIs.

Thoughts?

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: should Scala import scala.collection.JavaConversions._ by default?

HamsterofDeath
automatically imported: yes
implicitly converted: no

-------- Original-Nachricht --------
> Datum: Tue, 27 Jul 2010 10:33:45 +0100
> Von: James Strachan <[hidden email]>
> An: Scala User list <[hidden email]>
> Betreff: [scala-user] should Scala import scala.collection.JavaConversions._ by default?

> Groovy (and I think Clojure) makes sure that there's no real
> difference between java.util collections and the languages collection
> API. This really helps working with existing Java APIs; developers
> don't have to think if an object is a Java or Groovy List, its just a
> List. Scala took a different tack to keep them totally separate and
> require explicit developer interaction if you wish to consider
> java.util collections to be collections in a Scala like way.
>
> In those cases when you are using Scala to work with existing Java
> collection APIs (of which there's a zillion out there), newbies have
> to remember to add the "import scala.collection.JavaConversions._"
> statement to their source file or REPL shell to be able to use Java
> collections in a Scala way. While in the grand scheme of things not a
> huge biggie - it is yet one more new thing newbies have to know and
> remember.  (Plus some IDEs have a nasty habit of removing this import
> when tidying up imports ;-).
>
> In an alternative reality where the Scala library was part of the
> JDK's distribution, we'd probably add implicit conversions on
> companion objects for java.util.{Iterator, Collection, List, Set} so
> that java.util collections always act like scala.collections out of
> the box.
>
> So I wondered; should Scala import JavaConversions._ by default? This
> would basically be like fixing the JDK, simulating those implicit
> conversions being on java.util companion objects?
>
> It may be a small change but think of all those scala developers -
> particularly newbies - either in REPLs or in source code having to
> remember to cut and paste that line of code so they can iterate
> through their java.util collection in some existing
> Java/Groovy/Clojure API. IMHO out of the box Scala should know how to
> iterate over the java.util collections which are so widely adopted
> throughout the Java ecosystem without developers having to remember a
> magic import to cut and paste (an import which is pretty hard to find
> faced with the scaladoc for the scala library I might add).
>
> I guess a downside to this idea is, what if folks want to use a
> different implicit conversion to those supplied in
> scala.collection.JavaConversions. I wonder if the compiler could just
> have a few fall-back imports which are used if no other mplicit
> conversions can be found; e.g. if an implicit conversion cannot be
> found, try importing scala.collection.JavaConversions._ (and maybe any
> other implicit conversions we add to scala-library for fixing the
> JDK). Or have a little list of types (like the collection interfaces
> from java.util) which we have default implicit conversions used if the
> developer does not specify any? i.e. let users supply alternative
> implicit conversions if required - but by default the scala compiler
> would just do the right thing for java.util APIs.
>
> Thoughts?
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/

--
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: should Scala import scala.collection.JavaConversions._ by default?

Kevin Wright-3
In reply to this post by jstrachan
Absolutely not!

We need to provide Java interop and, yes, this ability must be offered by the main scala library.
But it isn't really *core* Scala, it's a library, just like actors.
and... just like actors, it's very possible to provide alternate implementations

I don't want to see any more implicits pulled into scope than are strictly necessary.
Also, the vast majority of my code doesn't need to interact with Java collections.

As a case in point: JavaConversions is currently broken, and I'm working with scalaj instead

So as someone who's actually using this stuff in anger, and in production,
I'm very grateful that it's optional and want to see it kept that way.



On 27 July 2010 10:33, James Strachan <[hidden email]> wrote:
Groovy (and I think Clojure) makes sure that there's no real
difference between java.util collections and the languages collection
API. This really helps working with existing Java APIs; developers
don't have to think if an object is a Java or Groovy List, its just a
List. Scala took a different tack to keep them totally separate and
require explicit developer interaction if you wish to consider
java.util collections to be collections in a Scala like way.

In those cases when you are using Scala to work with existing Java
collection APIs (of which there's a zillion out there), newbies have
to remember to add the "import scala.collection.JavaConversions._"
statement to their source file or REPL shell to be able to use Java
collections in a Scala way. While in the grand scheme of things not a
huge biggie - it is yet one more new thing newbies have to know and
remember.  (Plus some IDEs have a nasty habit of removing this import
when tidying up imports ;-).

In an alternative reality where the Scala library was part of the
JDK's distribution, we'd probably add implicit conversions on
companion objects for java.util.{Iterator, Collection, List, Set} so
that java.util collections always act like scala.collections out of
the box.

So I wondered; should Scala import JavaConversions._ by default? This
would basically be like fixing the JDK, simulating those implicit
conversions being on java.util companion objects?

It may be a small change but think of all those scala developers -
particularly newbies - either in REPLs or in source code having to
remember to cut and paste that line of code so they can iterate
through their java.util collection in some existing
Java/Groovy/Clojure API. IMHO out of the box Scala should know how to
iterate over the java.util collections which are so widely adopted
throughout the Java ecosystem without developers having to remember a
magic import to cut and paste (an import which is pretty hard to find
faced with the scaladoc for the scala library I might add).

I guess a downside to this idea is, what if folks want to use a
different implicit conversion to those supplied in
scala.collection.JavaConversions. I wonder if the compiler could just
have a few fall-back imports which are used if no other mplicit
conversions can be found; e.g. if an implicit conversion cannot be
found, try importing scala.collection.JavaConversions._ (and maybe any
other implicit conversions we add to scala-library for fixing the
JDK). Or have a little list of types (like the collection interfaces
from java.util) which we have default implicit conversions used if the
developer does not specify any? i.e. let users supply alternative
implicit conversions if required - but by default the scala compiler
would just do the right thing for java.util APIs.

Thoughts?

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/



--
Kevin Wright

mail/google talk: [hidden email]
wave: [hidden email]
skype: kev.lee.wright
twitter: @thecoda

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: should Scala import scala.collection.JavaConversions._ by default?

jstrachan
On 27 July 2010 11:24, Kevin Wright <[hidden email]> wrote:

> Absolutely not!
> We need to provide Java interop and, yes, this ability must be offered by
> the main scala library.
> But it isn't really *core* Scala, it's a library, just like actors.
> and... just like actors, it's very possible to provide alternate
> implementations
> I don't want to see any more implicits pulled into scope than are strictly
> necessary.
> Also, the vast majority of my code doesn't need to interact with Java
> collections.

Then lucky you :). However others have to work with Java code, there's
quite a bit of it out there...


> As a case in point: JavaConversions is currently broken, and I'm working
> with scalaj instead
> (see https://lampsvn.epfl.ch/trac/scala/ticket/3688)

I'm all for fixing things that a broken


> So as someone who's actually using this stuff in anger, and in production,
> I'm very grateful that it's optional and want to see it kept that way.

As I said, we should allow folks to override it if they want to use
alternatives. I just don't think Scala should barf with a cryptic
error message if a newbie tries to use a for loop on a java.util.List.

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: should Scala import scala.collection.JavaConversions._ by default?

Stefan Langer-4
I'm with Kevin on this one.

No automatic import and no automatic conversions.
If you have to interop with Java Collections then take the time to
learn the details even if you are a newbie and if you are not capable
of this then I think you should not use Scala as you are more then
likley to shoot yourself in the foot.

-Stefan

2010/7/27 James Strachan <[hidden email]>:

> On 27 July 2010 11:24, Kevin Wright <[hidden email]> wrote:
>> Absolutely not!
>> We need to provide Java interop and, yes, this ability must be offered by
>> the main scala library.
>> But it isn't really *core* Scala, it's a library, just like actors.
>> and... just like actors, it's very possible to provide alternate
>> implementations
>> I don't want to see any more implicits pulled into scope than are strictly
>> necessary.
>> Also, the vast majority of my code doesn't need to interact with Java
>> collections.
>
> Then lucky you :). However others have to work with Java code, there's
> quite a bit of it out there...
>
>
>> As a case in point: JavaConversions is currently broken, and I'm working
>> with scalaj instead
>> (see https://lampsvn.epfl.ch/trac/scala/ticket/3688)
>
> I'm all for fixing things that a broken
>
>
>> So as someone who's actually using this stuff in anger, and in production,
>> I'm very grateful that it's optional and want to see it kept that way.
>
> As I said, we should allow folks to override it if they want to use
> alternatives. I just don't think Scala should barf with a cryptic
> error message if a newbie tries to use a for loop on a java.util.List.
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: should Scala import scala.collection.JavaConversions._ by default?

Kevin Wright-3
There's another angle to this; making one part of interop automatic will lull people into a false sense of security.

people will still have to deal with differing property conventions, null<->Option conversions, checked exception handling, etc...
If you need deep Java interop then it should be explicit and you should know exactly what you're doing.
an import for converting collections really is just the tip of the iceberg when it comes to the possible challenges


I'm currently working on a scalaj-spring library that will deal with many of these issues when using Scala objects within a Spring DI container.
So I guess I'm pretty far into the deep end of this stuff,
and my experience so far is that implicits should be kept tightly scoped and under strict control if you don't want nasty surprises.


OTOH, I'm all for having a static analysis tool or compiler-plugin here
something that would advise you of implicits available on the classpath, potentially able to *fix*  non-compiling code.



On 27 July 2010 13:08, Stefan Langer <[hidden email]> wrote:
I'm with Kevin on this one.

No automatic import and no automatic conversions.
If you have to interop with Java Collections then take the time to
learn the details even if you are a newbie and if you are not capable
of this then I think you should not use Scala as you are more then
likley to shoot yourself in the foot.

-Stefan

2010/7/27 James Strachan <[hidden email]>:
> On 27 July 2010 11:24, Kevin Wright <[hidden email]> wrote:
>> Absolutely not!
>> We need to provide Java interop and, yes, this ability must be offered by
>> the main scala library.
>> But it isn't really *core* Scala, it's a library, just like actors.
>> and... just like actors, it's very possible to provide alternate
>> implementations
>> I don't want to see any more implicits pulled into scope than are strictly
>> necessary.
>> Also, the vast majority of my code doesn't need to interact with Java
>> collections.
>
> Then lucky you :). However others have to work with Java code, there's
> quite a bit of it out there...
>
>
>> As a case in point: JavaConversions is currently broken, and I'm working
>> with scalaj instead
>> (see https://lampsvn.epfl.ch/trac/scala/ticket/3688)
>
> I'm all for fixing things that a broken
>
>
>> So as someone who's actually using this stuff in anger, and in production,
>> I'm very grateful that it's optional and want to see it kept that way.
>
> As I said, we should allow folks to override it if they want to use
> alternatives. I just don't think Scala should barf with a cryptic
> error message if a newbie tries to use a for loop on a java.util.List.
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>



--
Kevin Wright

mail/google talk: [hidden email]
wave: [hidden email]
skype: kev.lee.wright
twitter: @thecoda

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Fwd: [scala-user] should Scala import scala.collection.JavaConversions._ by default?

Heiko Seeberger-4
In reply to this post by jstrachan
---------- Forwarded message ----------
From: Heiko Seeberger <[hidden email]>
Date: Tuesday, July 27, 2010
Subject: [scala-user] should Scala import
scala.collection.JavaConversions._ by default?
To: James Strachan <[hidden email]>


Jamses,
I disagree.
From a Scala newbie perspective:Have you ever considered that newbies
might feel confused that they can call map or filter on a Java
collection which does not offer these methods without doing something
special (importing the implicits)?

From a Scala expert perspective:Let's keep things simple and limit the
implicits that are imported by default to the absolute minimum.
Heiko


On 27 July 2010 11:33, James Strachan <[hidden email]> wrote:

Groovy (and I think Clojure) makes sure that there's no real
difference between java.util collections and the languages collection
API. This really helps working with existing Java APIs; developers
don't have to think if an object is a Java or Groovy List, its just a
List. Scala took a different tack to keep them totally separate and
require explicit developer interaction if you wish to consider
java.util collections to be collections in a Scala like way.

In those cases when you are using Scala to work with existing Java
collection APIs (of which there's a zillion out there), newbies have
to remember to add the "import scala.collection.JavaConversions._"
statement to their source file or REPL shell to be able to use Java
collections in a Scala way. While in the grand scheme of things not a
huge biggie - it is yet one more new thing newbies have to know and
remember.  (Plus some IDEs have a nasty habit of removing this import
when tidying up imports ;-).

In an alternative reality where the Scala library was part of the
JDK's distribution, we'd probably add implicit conversions on
companion objects for java.util.{Iterator, Collection, List, Set} so
that java.util collections always act like scala.collections out of
the box.

So I wondered; should Scala import JavaConversions._ by default? This
would basically be like fixing the JDK, simulating those implicit
conversions being on java.util companion objects?

It may be a small change but think of all those scala developers -
particularly newbies - either in REPLs or in source code having to
remember to cut and paste that line of code so they can iterate
through their java.util collection in some existing
Java/Groovy/Clojure API. IMHO out of the box Scala should know how to
iterate over the java.util collections which are so widely adopted
throughout the Java ecosystem without developers having to remember a
magic import to cut and paste (an import which is pretty hard to find
faced with the scaladoc for the scala library I might add).

I guess a downside to this idea is, what if folks want to use a
different implicit conversion to those supplied in
scala.collection.JavaConversions. I wonder if the compiler could just
have a few fall-back imports which are used if no other mplicit
conversions can be found; e.g. if an implicit conversion cannot be
found, try importing scala.collection.JavaConversions._ (and maybe any
other implicit conversions we add to scala-library for fixing the
JDK). Or have a little list of types (like the collection interfaces
from java.util) which we have default implicit conversions used if the
developer does not specify any? i.e. let users supply alternative
implicit conversions if required - but by default the scala compiler
would just do the right thing for java.util APIs.

Thoughts?

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/


--
Heiko Seeberger

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net
Stambecco, highly scalable computing: stambecco.org
Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting
through Actors: akkasource.org




--
Heiko Seeberger

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net
Stambecco, highly scalable computing: stambecco.org
Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting
through Actors: akkasource.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: should Scala import scala.collection.JavaConversions._ by default?

James Moore
In reply to this post by jstrachan
On Tue, Jul 27, 2010 at 2:33 AM, James Strachan
<[hidden email]> wrote:
> In those cases when you are using Scala to work with existing Java
> collection APIs (of which there's a zillion out there), newbies have
> to remember to add the "import scala.collection.JavaConversions._"

I wouldn't assume that newbie to Scala means that much Java
experience.  I've been using the JVM for a while, but mostly with
JRuby, not Java, and I suspect that sort of audience is fairly
important for something like Scala.

Personally, I think most of the growth in non-Java languages on the
JVM is going to come from outside the Java community.  From the point
of view of Scala, that seems like a requirement.  Java is a pretty
small slice of the programming world, and if you're aiming to convert
a small slice of a small slice, you're not going to matter much.

I'm completely biased because I've been spending too much time in the
mobile space.  But right now, things are changing and they're changing
quickly.  Think about Objective C; a couple years ago, it was a
completely uninteresting backwater.  Now it matters, but only because
of the iPhone.  Scala may have a similar opportunity with Android.
Lots of newbies will be wandering into the the Android world and
hitting Java.  And they don't care _at all_ about Java, yet.  Get them
now while you've got a chance.  You're not going to get another
opportunity like this.

--
James Moore
[hidden email]
http://blog.restphone.com/
Loading...