"import" best practice?

[Mitchell Hashimoto]

Hello,

New to the whole Scala ecosystem, I've been reading various open
source projects and so on but can't seem to pinpoint a convention or
community practice for this specific question I have... What is the
best practice for import statements?

I realize this question is vague, so more specifically:

* Try to avoid wildcard ('_') imports as much as possible?
* If only one method uses some identifier heavily, is it looked down
upon to put the import at the top of the method definition? Should I
put it outside? etc.

I just want to write code that is acceptable by the community
standards, so I figured I'd ask here.

Thanks,
Mitchell

[Lex]

You will have to use wildcards _ to pull in the implicits. Other than that, just use common sense.

[Stefan Langer]

Problem is that most IDEs for scalas do not handle the import stuff
too well. One thing I find important for imports is to keep their
scope as tight as possible to prevent accidental implicit inclusion.
I'm also a fan of always specifiing the complete import although I'm
being lazy on that lately and use the short time more often.

-Stefam

2011/3/4 Lex <lex...@gmail.com>:

[Mitchell Hashimoto]

On Friday, March 4, 2011 1:32:49 AM UTC-8, Stefan Langer wrote:

Problem is that most IDEs for scalas do not handle the import stuff
too well. One thing I find important for imports is to keep their
scope as tight as possible to prevent accidental implicit inclusion.
I'm also a fan of always specifiing the complete import although I'm
being lazy on that lately and use the short time more often.

-Stefam

Thanks for your notes. I'm an emacs user so "IDE" support is not an issue, I prefer to do that manually.

Tight scoping is what I prefer, great.

Best,

Mitchell

[Josh Suereth]

On Thu, Mar 3, 2011 at 9:38 PM, Lex <lex...@gmail.com> wrote:

You will have to use wildcards _ to pull in the implicits. Other than that, just use common sense.

This is not true.  You can pull implicits in individually without wildcards.  Explicit imports have 'priority' over wildcard imports.  Because of this, you can shadow wildcard imports with an explicit import.

 

On Thu, Mar 3, 2011 at 8:08 PM, Mitchell Hashimoto <mitchell....@gmail.com> wrote:

Hello,

New to the whole Scala ecosystem, I've been reading various open
source projects and so on but can't seem to pinpoint a convention or
community practice for this specific question I have... What is the
best practice for import statements?

My basic rules with imports for a team with a 'large set of developers':

(1) Try to keep them explicit (use {} as needed).   There are automated tools that can do this for you.  Again, I find myself being lazy here when not using an IDE.

(2) Try to limit the scope of imported implicits.  If one is needed for an entire file, place it at the top, otherwise try to limit it to the scope where it's used.   Best, is to find a way to associate an implicit with the types it works with, via companion objects or package objects.  I prefer keeping project-common implicits in a package-level trait for that project.   I probably wouldn't do this for an open source library, but for company projects, I think it can help out significantly by encouraging common 'pimp' implicits across the company *and* creating a common place to control these (hopefully aiding readability across the entire company).

(3) Try to stick to a common set of name aliasing imports.  e.g. import java.util.{Collection => JCollection} // I should try to always use JCollection in my source files).

Hope that helps.

[Kevin Wright]

I take a slightly different stance on that last one, importing `java.{util=>ju}` and then referring to `ju.Collection`.

Inspired, in part, by the Scala library source code

 

Hope that helps.

--
Kevin Wright

gtalk / msn : kev.lee...@gmail.com

mail: kevin....@scalatechnology.com

vibe / skype: kev.lee.wright

quora: http://www.quora.com/Kevin-Wright
twitter: @thecoda

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[Josh Suereth]

Again, the key to name rewriting is consistency ;)  Whichever you pick for your code, keep it consistent.

[Blair Zajac]

On 3/3/2011 5:08 PM, Mitchell Hashimoto wrote:
> Hello,
>
> New to the whole Scala ecosystem, I've been reading various open
> source projects and so on but can't seem to pinpoint a convention or
> community practice for this specific question I have... What is the
> best practice for import statements?

We follow the GWT coding standard on ordering imports:

http://code.google.com/webtoolkit/makinggwtbetter.html#codestyle

For the collection classes, we do

import scala.collection.{immutable,
mutable}

and then refer to any classes in there using mutable.HashMap.

As others have stated, we don't use wildcard imports.

Blair

[Danno]

I also like having imports in my local block first, unless it is
required further out then I refactor it's location as needed. Don't
know if that's convention, I just like the way it looks.



On Mar 3, 6:08 pm, Mitchell Hashimoto <mitchell.hashim...@gmail.com>
wrote:

[Brian Maso]

Dude, you sound like a corporate Java programmer. Best practices? We don't need no stinkin' best practices!

Seriously, just go with the flow. Most interesting stuff happens *after* the imports.

I like your idea of putting the import of a particular identifier close to where its used heavily -- couldn't hurt to make dense code a little more readable.

Brian Maso

--
Best regards,
Brian Maso
(949) 395-8551
br...@blumenfeld-maso.com

[Mitchell Hashimoto]

Brian,

On Tue, Mar 8, 2011 at 4:00 PM, Brian Maso <br...@blumenfeld-maso.com> wrote:
> Dude, you sound like a corporate Java programmer. Best practices? We don't
> need no stinkin' best practices!

Heh, I take that offensively! ;)

I wasn't asking for hard and fast rules, just ways to write idiomatic
Scala so that if others view my code they won't be like "What was this
guy thinking?"

Nothing too enterprisey ;)

Best,
Mitchell

[Philippe Lhoste]

On 09/03/2011 01:17, Mitchell Hashimoto wrote:
> I wasn't asking for hard and fast rules, just ways to write idiomatic
> Scala so that if others view my code they won't be like "What was this
> guy thinking?"

Maybe look at a number of different Scala projects, and try to see if there is a trend...
And maybe the Scala style guide (which tries to capture best practices in Scala) has a
word on imports (I don't recall...).

>>> * Try to avoid wildcard ('_') imports as much as possible?

It depends... It is nearly unavoidable when you import the methods. It might be better to
use _ instead of a very long list of classes...
Although I used an explicit list of imports in a series of tutorials, as it might have an
educational purpose (showing where the classes come from in a complex set of Java packages):

import java.net.URL

import org.apache.pivot
import pivot.beans.Bindable, pivot.util.Resources,
pivot.util.concurrent.TaskExecutionException
import pivot.collections.{ Map, Sequence }
import pivot.wtk.
{
Label,
ListView,
ListViewSelectionListener,
Span,
Window
}

At least, it is less ugly than in Java... :-)

>>> * If only one method uses some identifier heavily, is it looked down
>>> upon to put the import at the top of the method definition? Should I
>>> put it outside? etc.

As Brian said, it is a good idea to put the import inside the method, to limit the scope
of the imported classes. Another nice things with Scala imports, following best practice
to declare variables near the point where they are used.

I also saw stuff like defining an 'object', and immediately after importing its content to
be used directly in the companion class (as regular 'static' items).

object TT
{
val Message = "Foo"
def main(args: Array[String])
{
val tt = new TT
tt.doStuff
}

def output(s: String) { println("Message: " + s) }
}

import TT._

class TT
{
def doStuff() { output(Message) }
}

(Instead of def doStuff() { TT.output(TT.Message) })
(Not sure why they have visibility on their private parts but no direct access on the
elements.)

--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --

[john sullivan]

On Fri, Mar 4, 2011 at 11:13 PM, Mitchell Hashimoto <mitchell....@gmail.com> wrote:

Thanks for your notes. I'm an emacs user so "IDE" support is not an issue, I prefer to do that manually.

FWIW, I've been quite happy developing in Emacs with ENSIME ( https://github.com/aemoncannon/ensime ) the last week or so. It's got an "organize imports" refactoring, C-c C-r o, that works. In general, it seems to keep any wildcard imports you have, and combine singleton imports with the {} syntax.

I'd like to have a standard set of conventions for managing my imports too, but it's hard to focus on things like that when there are so many other things going on (new IDE, new build tool, a half a dozen or so new libraries).