Comments on: How packages work in Scala

By: Dean Thompson

Dean Thompson — Fri, 01 Apr 2011 14:31:11 +0000

Here’s the Scala 2.8 solution: http://www.artima.com/scalazine/articles/chained_package_clauses_in_scala.html

By: ittay

ittay — Thu, 01 Oct 2009 05:04:47 +0000

I agree with @Gary. As far as I could see, this feature means only something I can trip over and requires me to think more carefully about how I name packages. Where does it come in handy?

Also, why couldn’t packages be “reopened” instead of being always shadowed? That way, in the example, kittens would have been added to the existing ‘java’ namespace.

By: Gary

Gary — Sat, 08 Aug 2009 15:58:52 +0000

The article starts by saying that people often don’t get to stage 5, acceptance, and that the package system is actually “quite nice.” But the article only goes on to decribe the problems of shadowing and package hijacking. What are the positives that make these risks worthwhile? What the practices enabled by the current scheme that are quite nice? Take us to stage 5!

By: Bhaskar Maddala

Bhaskar Maddala — Sat, 18 Jul 2009 14:15:51 +0000

It is perfectly acceptable for me to want to live long, actually really long. :)
package woodoo.charlaton{
object trickery {
private def doSomeMagic = java.lang.Math.random * 100
def liveLong = if(doSomeMagic == 1000) “You will live long” else “Die Now!!”
}

package java.lang{
object Math{
val random = 10
}
}
}
it occurs to me that most people are thinking of packages in scala as a means of code organization (coming from a Java world, this is the immediate model) rather than as nested structures and are as a result put off by what they might consider to be name shadowing.

However I am not certain that any of your proposed solutions on naming conventions

- Public projects simply get shortened to projectname as the top level package
- Private projects get shortened to companyname.projectname
- Packages structures are kept fairly shallow

resolves the issue. They just make it easier for programmers to use the feature without understanding it, but in my experience this results in more poorly written code in the long run.

If such conventions were to be used on a code base, I would add to the above proposed solution on naming conventions

- All packages must contain an object or class type

As an example
net.webbify.controller would become just controller dropping the TLD and projectname (if webbify has no object or type classes)

This enforces your third criterion of keeping package structures shallow.

You indicate that most people have taken to fully qualifying imports. This is only required in the cases where the type being referenced is from a third party source.

I like my packages as they are now

By: david

david — Fri, 17 Jul 2009 14:31:06 +0000

My naming conventions are basically as follows:

- Public projects simply get shortened to projectname as the top level package
- Private projects get shortened to companyname.projectname
- Packages structures are kept fairly shallow

It’s almost functionally equivalent to just dropping the TLD, so

com.foo.bar

becomes

foo.bar