Scala wrappers package; com.google.collect.scala?

[Blair Zajac]

I'm considering writing an open-source Scala wrapper library around the Google
Collection class to make the code more Scala idiomatic, for example to allow
collections to be used in for loops.

The Google Collection immutable classes have different performance
characteristics than the built in Scala immutable classes which is why I'm
interested in doing this. For example, the #size() method on a Scala immutable
set needs a synchronized block. One advantage Scala classes have is sharing of
the underlying data structures if one immutable instance adds or subtracts
elements from another, but in our servers this doesn't gain us much and I much
rather prefer Google Collection's immutable classes.

My first thought for this package name was

com.imageworks.collection.google

which seems odd to have two separate company names. Would it be possible to get
permission to put this package into com.google.collect.scala? If Google decides
to approve Scala as a language then this package could be renamed.

Regards,
Blair

--
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
<bl...@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/

[Kevin Bourrillion]

I'm open to the possibility of adding a com.google.common.collect.scala to our project -- if you're open to contributing and maintaining it!  Go ahead and polish up some initial ideas and share some code with the list.  Hopefully, we can get some other Scala aficianados who are familiar with Google Collections to review it.

--
Google Collections Library - users list
http://groups.google.com/group/google-collections-dev?hl=en

To unsubscribe, send email to:
google-collections...@googlegroups.com

--
Kevin Bourrillion @ Google
internal:  http://go/javalibraries
external: guava-libraries.googlecode.com

[Blair Zajac]

Great!

So if there are Scala wrappers for other parts of Google Collections or Guava,
is the plan for each to get a scala subpackage? Or what about
com.google.common.scala.collect? That way a IO wrapper at
com.google.common.scala.io would be a neighboring package? I'm just asking,
don't have an opinion on which would be better.

How were you thinking of the managing the code? My thought was to start a new
project, named Scoogle Collections, that would provide a separate jar file. It
doesn't sound like you would want Scala code mixed into the Google Collections
code since you'd need a Scala compiler plus the Scala is moving to 2.8.x which
is significantly changing the collection library and I may provide 2.7.x and a
2.8.x versions.

I have wrappers now around ImmutableSet, ImmutableSet.Builder, ImmutableMap and
ImmutableMap.Builder, I'm just waiting for legal approval to put the code out.

Regards,
Blair

[Kevin Bourrillion]

Would it make more sense to put these in the same package as the Java stuff, just in a different source root under /trunk/?  e.g., trunk/scala/com/google/common/collect?  It would be built using separate ant rules in build.xml -- it would not be part of the standard distribution of the library, but it'd be the next best thing.

I'd still like to hear from a small number (>= 3?) of Scala developers that there's a consensus on how this should look and work.  

[Jared Levy]

What's the advantage of that over Blair's proposal for a separate Scoogle Collections project?

Having separate projects seems simpler and allows independent releases.

[Kevin Bourrillion]

If the projects are separate, we have problems keeping them in sync with each other, and even if we do our best, users can still end up with a version conflict.

As I said before, I'm "open to the possibility", that's all.

[Blair Zajac]

Typically Scala wrappers have the same name as the Java package, so having it in
the exact same package wouldn't work, unless you prefix the names with 'S' or
something, which would be ugly. And I don't think we would want Java users
doing an import * and pick up Scala classes.

The wrappers I wrote use the exact same class names, except for the Builders
because Scala idioms don't use static inner classes, so those are named
ImmutableSetBuilder and ImmutableMapBuilder. They also have the same style of
Google methods and extend the Scala Set and Map interfaces.

Blair

Kevin Bourrillion wrote:
> Would it make more sense to put these in the /same/ package as the Java

> stuff, just in a different source root under /trunk/? e.g.,
> trunk/scala/com/google/common/collect? It would be built using separate
> ant rules in build.xml -- it would not be part of the standard
> distribution of the library, but it'd be the next best thing.
>
> I'd still like to hear from a small number (>= 3?) of Scala developers
> that there's a consensus on how this should look and work.
>
> On Thu, Nov 19, 2009 at 1:05 PM, Blair Zajac <bl...@orcaware.com
> <mailto:bl...@orcaware.com>> wrote:
>
> Great!
>
> So if there are Scala wrappers for other parts of Google Collections
> or Guava, is the plan for each to get a scala subpackage? Or what
> about com.google.common.scala.collect? That way a IO wrapper at

> com.google.common.scala.io <http://com.google.common.scala.io> would

> be a neighboring package? I'm just asking, don't have an opinion on
> which would be better.
>
> How were you thinking of the managing the code? My thought was to
> start a new project, named Scoogle Collections, that would provide a
> separate jar file. It doesn't sound like you would want Scala code
> mixed into the Google Collections code since you'd need a Scala
> compiler plus the Scala is moving to 2.8.x which is significantly
> changing the collection library and I may provide 2.7.x and a 2.8.x
> versions.
>
> I have wrappers now around ImmutableSet, ImmutableSet.Builder,
> ImmutableMap and ImmutableMap.Builder, I'm just waiting for legal
> approval to put the code out.
>
> Regards,
> Blair
>
> Kevin Bourrillion wrote:
>
> I'm open to the possibility of adding a
> com.google.common.collect.scala to our project -- if you're open
> to contributing and maintaining it! Go ahead and polish up some
> initial ideas and share some code with the list. Hopefully, we
> can get some other Scala aficianados who are familiar with
> Google Collections to review it.
>
>
>
> On Sun, Nov 15, 2009 at 1:24 PM, Blair Zajac <bl...@orcaware.com

> <mailto:bl...@orcaware.com> <mailto:bl...@orcaware.com

[Blair Zajac]

What kind of version conflict are you thinking of? 1.0 is going to lock down
the library for a long time, right?

It would be nice to have them together, but given that the Scala Compiler
sometimes generates binary incompatible class files between minor compiler
updates and that I intend to have Scoogle Collections support the 2.7.x and
2.8.x lines does suggest a separate package.

2.7.x and 2.8.x differ significantly in the collection classes and the Set and
Map interfaces that the wrappers would extend. It's like supporting a Python 2
and Python 3 package with the same functionality, same code, with minor differences.

Blair

Kevin Bourrillion wrote:
> If the projects are separate, we have problems keeping them in sync with
> each other, and even if we do our best, users can still end up with a
> version conflict.
>
> As I said before, I'm "open to the possibility", that's all.
>
>
> On Mon, Nov 23, 2009 at 9:31 AM, Jared Levy <jared....@gmail.com
> <mailto:jared....@gmail.com>> wrote:
>
> What's the advantage of that over Blair's proposal for a separate
> Scoogle Collections project?
>
> Having separate projects seems simpler and allows independent releases.
>
>
> On Mon, Nov 23, 2009 at 9:02 AM, Kevin Bourrillion

> <kev...@google.com <mailto:kev...@google.com>> wrote:
>
> Would it make more sense to put these in the /same/ package as

> the Java stuff, just in a different source root under /trunk/?
> e.g., trunk/scala/com/google/common/collect? It would be built
> using separate ant rules in build.xml -- it would not be part of
> the standard distribution of the library, but it'd be the next
> best thing.
>
> I'd still like to hear from a small number (>= 3?) of Scala
> developers that there's a consensus on how this should look and
> work.
>
> On Thu, Nov 19, 2009 at 1:05 PM, Blair Zajac <bl...@orcaware.com
> <mailto:bl...@orcaware.com>> wrote:
>
> Great!
>
> So if there are Scala wrappers for other parts of Google
> Collections or Guava, is the plan for each to get a scala
> subpackage? Or what about com.google.common.scala.collect?
> That way a IO wrapper at com.google.common.scala.io

> <http://com.google.common.scala.io> would be a neighboring

> package? I'm just asking, don't have an opinion on which
> would be better.
>
> How were you thinking of the managing the code? My thought
> was to start a new project, named Scoogle Collections, that
> would provide a separate jar file. It doesn't sound like
> you would want Scala code mixed into the Google Collections
> code since you'd need a Scala compiler plus the Scala is
> moving to 2.8.x which is significantly changing the
> collection library and I may provide 2.7.x and a 2.8.x versions.
>
> I have wrappers now around ImmutableSet,
> ImmutableSet.Builder, ImmutableMap and ImmutableMap.Builder,
> I'm just waiting for legal approval to put the code out.
>
> Regards,
> Blair
>
> Kevin Bourrillion wrote:
>
> I'm open to the possibility of adding a
> com.google.common.collect.scala to our project -- if
> you're open to contributing and maintaining it! Go
> ahead and polish up some initial ideas and share some
> code with the list. Hopefully, we can get some other
> Scala aficianados who are familiar with Google
> Collections to review it.
>
>
>
> On Sun, Nov 15, 2009 at 1:24 PM, Blair Zajac
> <bl...@orcaware.com <mailto:bl...@orcaware.com>

> <mailto:bl...@orcaware.com <mailto:bl...@orcaware.com>>>

[Kevin Bourrillion]

On Mon, Nov 23, 2009 at 9:42 AM, Blair Zajac <bl...@orcaware.com> wrote:

What kind of version conflict are you thinking of?  1.0 is going to lock down the library for a long time, right?

Yes, as long as your scala package needs only access to public APIs, which now sounds to be the case.  You could still have the opposite problem, but it's not a big deal.

Mostly I was just entertaining the possibility that our project could treat scala users as first-class.  However, that's probably unrealistic given that none of us use Scala at Google (and I doubt will any time soon either).

So, a separate project is almost certainly going to be the simpler path at least for now.  However, I think our naming people might be less than thrilled with your use of the word "Scoogle" :-)  You might do better to keep the name per se independent of any variant of "Google".  Obviously the description can say what it does in proper detail, it's just that names are... funny things.

[Blair Zajac]

Kevin Bourrillion wrote:
> On Mon, Nov 23, 2009 at 9:42 AM, Blair Zajac <bl...@orcaware.com
> <mailto:bl...@orcaware.com>> wrote:
>
> Mostly I was just entertaining the possibility that our project could
> treat scala users as first-class. However, that's probably unrealistic
> given that none of us use Scala at Google (and I doubt will any time
> soon either).

Fyi, Lex Spoon is a Scala contributor and a Google employee.

> So, a separate project is almost certainly going to be the simpler path
> at least for now. However, I think our naming people might be less than
> thrilled with your use of the word "Scoogle" :-) You might do better to
> keep the name per se independent of any variant of "Google". Obviously
> the description can say what it does in proper detail, it's just that
> names are... funny things.

Would a name with "Google" in it be any better? Wouldn't that imply that the
code was sourced from Google, which isn't the case. "Scoogle" implies, at least
to me, that it isn't an official Google project.

Blair

[Kevin Bourrillion]

On Mon, Nov 23, 2009 at 9:54 AM, Blair Zajac <bl...@orcaware.com> wrote:

Kevin Bourrillion wrote:

Mostly I was just entertaining the possibility that our project could treat scala users as first-class.  However, that's probably unrealistic given that none of us use Scala at Google (and I doubt will any time soon either).

Fyi, Lex Spoon is a Scala contributor and a Google employee.

Yep, I know Lex.  He's on GWT now, support for which is considered much more important for Google Collections.

 

So, a separate project is almost certainly going to be the simpler path at least for now.  However, I think our naming people might be less than thrilled with your use of the word "Scoogle" :-)  You might do better to keep the name per se independent of any variant of "Google".  Obviously the description can say what it does in proper detail, it's just that names are... funny things.

Would a name with "Google" in it be any better?

Definitely not; hence my suggestion that the path of least resistance would be to keep "any variant of 'Google'" (including the identity variant :-)) out of the name.  But if it's really important to you, I'll ask around.

[Blair Zajac]

If Google Collections are immediately becoming part of Guava, what something
like Scala Guava, Scala Guava Wrappers or Scala for Guava? Kinda has a nice
ryme :) "Guava" isn't as protected as "Google" is.

Are Google Collections as a package being deprecated then? Will the collections
in Guava be extended and modified beyond the 1.0

Blair

[Kevin Bourrillion]

<forehead thwap> 

Of course, patterning your name after Guava would be better on all counts!

Feel free to do what you want with it.. GuavaScala, ScalaGuava, ScavaGuala, whatever the heck :-)

Google Collections 1.0 won't be born deprecated :-) but there will never be a 1.0.1 or a 2.0.  All its code will get imported into Guava and then we'll be adding a LOT of functionality we've been holding back.