Preferred style for imports inside scala package

Hi Cay,

I now tend to write the longer versions. In 1) just because it is more symmetric to the rest of the universe (although it is tempting to go the short way here). In 2) because I find no other way to not get lost in medium-and-upper-sized projects; and I mean here that I want to look at the imports and quickly get what is going on.

Just my 2 euro-cents (as long as euro still exists, locally or globally)

--
Christos KK Loverdos
Sent from a mobile phone, probably in haste.

On 13 Δεκ 2011, at 20:29, Cay Horstmann wrote:

> I have two style questions about imports.
>
> 1) Is it preferred to write
>
> import scala.collection.mutable.ArrayBuffer
>
> or
>
> import collection.mutable.ArrayBuffer
>
> The second form is shorter, which seems the Scala way. But the first
> form seems easier for newcomers from Java.
>
> "Programming in Scala" uses the first form except in the Swing
> chapter, "Scala in Depth" uses the second form.
>
> 2) If the answer to 1) is to use the shorter form, what about nested
> packages? I found myself writing
>
> import xml._
> import xml.dtd._
>
> even though
>
> import xml._
> import dtd._
>
> would work just as well. I was nervous about accidental imports. Should I be?
>
> Thanks,
>
> Cay

I used to prefer the short form, until I once tried to refactor, renaming a package project-wide -- search was useless, and often things still compiled, using the same name from a different scope --ugh.  Never again.  It's fully qualified imports for me.

On 14 December 2011 06:04, Christos KK Loverdos <loverdos@gmail.com> wrote:

Hi Cay,

I now tend to write the longer versions. In 1) just because it is more symmetric to the rest of the universe (although it is tempting to go the short way here). In 2) because I find no other way to not get lost in medium-and-upper-sized projects; and I mean here that I want to look at the imports and quickly get what is going on.

Just my 2 euro-cents (as long as euro still exists, locally or globally)

--
Christos KK Loverdos
Sent from a mobile phone, probably in haste.

On 13 Δεκ 2011, at 20:29, Cay Horstmann <cay.horstmann@gmail.com> wrote:

> I have two style questions about imports.
>
> 1) Is it preferred to write
>
> import scala.collection.mutable.ArrayBuffer
>
> or
>
> import collection.mutable.ArrayBuffer
>
> The second form is shorter, which seems the Scala way. But the first
> form seems easier for newcomers from Java.
>
> "Programming in Scala" uses the first form except in the Swing
> chapter, "Scala in Depth" uses the second form.
>
> 2) If the answer to 1) is to use the shorter form, what about nested
> packages? I found myself writing
>
> import xml._
> import xml.dtd._
>
> even though
>
> import xml._
> import dtd._
>
> would work just as well. I was nervous about accidental imports. Should I be?
>
> Thanks,
>
> Cay

On 13/12/2011 22:55, Ken Scambler wrote:
> I used to prefer the short form, until I once tried to refactor,
> renaming a package project-wide -- search was useless, and often
> things still compiled, using the same name from a different scope
> --ugh. Never again. It's fully qualified imports for me.
>

Same here, for the same reasons :)

- Josh

On Tue, Dec 13, 2011 at 1:29 PM, Cay Horstmann <cay.horstmann@gmail.com> wrote:

I have two style questions about imports.

1) Is it preferred to write

import scala.collection.mutable.ArrayBuffer

or

import collection.mutable.ArrayBuffer

The second form is shorter, which seems the Scala way. But the first
form seems easier for newcomers from Java.

"Programming in Scala" uses the first form except in the Swing
chapter, "Scala in Depth" uses the second form.

2) If the answer to 1) is to use the shorter form, what about nested
packages? I found myself writing

import xml._
import xml.dtd._

even though

import xml._
import dtd._

would work just as well. I was nervous about accidental imports. Should I be?

Thanks,

Cay

Like you say, they seem mostly in the REPL. Just search for import.
You don't use the Scala library much in your book--it's not that kind
of book. But when you did, you consistently omitted the scala package:

import collection.immutable.HashMap
import collection.mutable.{HashMap=>MutableHashMap}
import annotation.switch
import collection.JavaConversions._

That's what I did too.

I didn't go further than that. I never have

import collection._
import mutable._

My rule was to use the full package name, but drop a redundant scala.
prefix. Is that defensible, or should I stick the scala prefix back
in?

Cheers,

Cay

On Wed, Dec 14, 2011 at 10:32 AM, Josh Suereth wrote:
> Note:  If you inform me where in Scala In Depth I use that import style, I
> will most likely change it (if you can do so in the next day).
>
> I used to prefer the second use case, but in all honesty I rely on automated
> tooling to convert the second use case to the first use case on a regular
> basis.  I wrote most of Scala In Depth with *just* the REPL, where you'll
> see code examples follow my writing style, vs. my preferred reading style.
>
> - Josh
>
>
> On Tue, Dec 13, 2011 at 1:29 PM, Cay Horstmann
> wrote:
>>
>> I have two style questions about imports.
>>
>> 1) Is it preferred to write
>>
>> import scala.collection.mutable.ArrayBuffer
>>
>> or
>>
>> import collection.mutable.ArrayBuffer
>>
>> The second form is shorter, which seems the Scala way. But the first
>> form seems easier for newcomers from Java.
>>
>> "Programming in Scala" uses the first form except in the Swing
>> chapter, "Scala in Depth" uses the second form.
>>
>> 2) If the answer to 1) is to use the shorter form, what about nested
>> packages? I found myself writing
>>
>> import xml._
>> import xml.dtd._
>>
>> even though
>>
>> import xml._
>> import dtd._
>>
>> would work just as well. I was nervous about accidental imports. Should I
>> be?
>>
>> Thanks,
>>
>> Cay
>
>

I'd say it's defensible.   Like I stated, If I had an 'auto import fixer" I'd want it to add the scala back in.   For a book with line-length restrictions (which I had), I think dropping some syntax for brevity is acceptable, as long as you can figure out what's going on easily enough.

On Wed, Dec 14, 2011 at 4:24 PM, Cay Horstmann <cay.horstmann@gmail.com> wrote:

Like you say, they seem mostly in the REPL. Just search for import.
You don't use the Scala library much in your book--it's not that kind
of book. But when you did, you consistently omitted the scala package:

import collection.immutable.HashMap
import collection.mutable.{HashMap=>MutableHashMap}
import annotation.switch
import collection.JavaConversions._

That's what I did too.

I didn't go further than that. I never have

import collection._
import mutable._

My rule was to use the full package name, but drop a redundant scala.
prefix. Is that defensible, or should I stick the scala prefix back
in?

Cheers,

Cay



On Wed, Dec 14, 2011 at 10:32 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:
> Note:  If you inform me where in Scala In Depth I use that import style, I
> will most likely change it (if you can do so in the next day).
>
> I used to prefer the second use case, but in all honesty I rely on automated
> tooling to convert the second use case to the first use case on a regular
> basis.  I wrote most of Scala In Depth with *just* the REPL, where you'll
> see code examples follow my writing style, vs. my preferred reading style.
>
> - Josh
>
>
> On Tue, Dec 13, 2011 at 1:29 PM, Cay Horstmann <cay.horstmann@gmail.com>
> wrote:
>>
>> I have two style questions about imports.
>>
>> 1) Is it preferred to write
>>
>> import scala.collection.mutable.ArrayBuffer
>>
>> or
>>
>> import collection.mutable.ArrayBuffer
>>
>> The second form is shorter, which seems the Scala way. But the first
>> form seems easier for newcomers from Java.
>>
>> "Programming in Scala" uses the first form except in the Swing
>> chapter, "Scala in Depth" uses the second form.
>>
>> 2) If the answer to 1) is to use the shorter form, what about nested
>> packages? I found myself writing
>>
>> import xml._
>> import xml.dtd._
>>
>> even though
>>
>> import xml._
>> import dtd._
>>
>> would work just as well. I was nervous about accidental imports. Should I
>> be?
>>
>> Thanks,
>>
>> Cay
>
>

Hiho,

I would also recommend to use the longer form. It's more precise (visually)
and states (and reminds you) exactly what you intend to import.

As I didn't use the shorter version ever I cannot say if the shorter version
has other problems (apart from the refactoring problem stated by Christos).

Greetings (also here: still my 2 Euro-Cents...)
Bernd

Am Dienstag, 13. Dezember 2011, 20:04:20 schrieb Christos KK Loverdos:
> Hi Cay,
>
> I now tend to write the longer versions. In 1) just because it is more
> symmetric to the rest of the universe (although it is tempting to go the
> short way here). In 2) because I find no other way to not get lost in
> medium-and-upper-sized projects; and I mean here that I want to look at
> the imports and quickly get what is going on.
>
> Just my 2 euro-cents (as long as euro still exists, locally or globally)
>
> --
> Christos KK Loverdos
> Sent from a mobile phone, probably in haste.
>
> On 13 Δεκ 2011, at 20:29, Cay Horstmann wrote:
> > I have two style questions about imports.
> >
> > 1) Is it preferred to write
> >
> > import scala.collection.mutable.ArrayBuffer
> >
> > or
> >
> > import collection.mutable.ArrayBuffer
> >
> > The second form is shorter, which seems the Scala way. But the first
> > form seems easier for newcomers from Java.
> >
> > "Programming in Scala" uses the first form except in the Swing
> > chapter, "Scala in Depth" uses the second form.
> >
> > 2) If the answer to 1) is to use the shorter form, what about nested
> > packages? I found myself writing
> >
> > import xml._
> > import xml.dtd._
> >
> > even though
> >
> > import xml._
> > import dtd._
> >
> > would work just as well. I was nervous about accidental imports. Should I
> > be?
> >
> > Thanks,
> >
> > Cay

Thanks, I couldn't agree more about those medium-to-large size
projects. I kept pondering this all day.

I just sent a note to my editor telling her I'd like to make the
change. Haven't heard back from her yet. But then I fired up the REPL
to write a quick script and watched my fingers go

import io._

Not

import scala.io._

Really, when you want to learn stuff, the shorter, the better. And I
want people to fire up the REPL and try things. That's how one learns.
Later, when they work on larger projects, they can stick scala.
everywhere--that's the least of their worries.

So, I guess if my editor says "hell, no", I'll stick with the short form :-)

Cheers,

Cay

On Tue, Dec 13, 2011 at 11:04 AM, Christos KK Loverdos
wrote:
> Hi Cay,
>
> I now tend to write the longer versions. In 1) just because it is more symmetric to the rest of the universe (although it is tempting to go the short way here). In 2) because I find no other way to not get lost in medium-and-upper-sized projects; and I mean here that I want to look at the imports and quickly get what is going on.
>
> Just my 2 euro-cents (as long as euro still exists, locally or globally)
>
> --
> Christos KK Loverdos
> Sent from a mobile phone, probably in haste.
>
> On 13 Δεκ 2011, at 20:29, Cay Horstmann wrote:
>
>> I have two style questions about imports.
>>
>> 1) Is it preferred to write
>>
>> import scala.collection.mutable.ArrayBuffer
>>
>> or
>>
>> import collection.mutable.ArrayBuffer
>>
>> The second form is shorter, which seems the Scala way. But the first
>> form seems easier for newcomers from Java.
>>
>> "Programming in Scala" uses the first form except in the Swing
>> chapter, "Scala in Depth" uses the second form.
>>
>> 2) If the answer to 1) is to use the shorter form, what about nested
>> packages? I found myself writing
>>
>> import xml._
>> import xml.dtd._
>>
>> even though
>>
>> import xml._
>> import dtd._
>>
>> would work just as well. I was nervous about accidental imports. Should I be?
>>
>> Thanks,
>>
>> Cay

On Tue, Dec 13, 2011 at 10:29:39AM -0800, Cay Horstmann said
> I have two style questions about imports.
>
> 1) Is it preferred to write
>
> import scala.collection.mutable.ArrayBuffer
>
> or
>
> import collection.mutable.ArrayBuffer

For the collections I will do

import scala.collection.{mutable,immutable}

especially when I'm going to use both kinds of collections in a source
file. It makes it so that everytime I refer to a collection type it
includes the mutability right there which is especially important in the
case of the base types. If I need something from collection (e.g.
Iterator) I'll add it to the import list.

def foo(xs: mutable.ArrayBuffer[_])

def bar(m: immutable.Map[_,_])

On Dec 16, 2011 6:04 AM, "Geoff Reedy" <geoff@programmer-monk.net> wrote:
>
> On Tue, Dec 13, 2011 at 10:29:39AM -0800, Cay Horstmann said
> > I have two style questions about imports.
> >
> > 1) Is it preferred to write
> >
> > import scala.collection.mutable.ArrayBuffer
> >
> > or
> >
> > import collection.mutable.ArrayBuffer
>
> For the collections I will do
>
> import scala.collection.{mutable,immutable}
>
> especially when I'm going to use both kinds of collections in a source
> file. It makes it so that everytime I refer to a collection type it
> includes the mutability right there which is especially important in the
> case of the base types. If I need something from collection (e.g.
> Iterator) I'll add it to the import list.
>
> def foo(xs: mutable.ArrayBuffer[_])

Wouldn't it be great if the type enforced the fact rather than rely on a name that is lost when you build around on top innit?

On Thu, Dec 15, 2011 at 1:38 PM, Tony Morris wrote:
>
> Wouldn't it be great if the type enforced the fact rather than rely on a
> name that is lost when you build around on top innit?

Most of the time, that's actually the case with type inference. It
breaks down with objects and with constructors, though. When I write

val v = new Fred("...")

or

val v = Fred.create("...")

then it's necessary to know what Fred means.

And in Scala, imports can introduce implicits. When I write

import Fred._

it's also necessary to know what Fred means.

Cheers,

Cay