Summary:
The second installment of a series of articles on the latest Scala release, Scala 2.8, Martin Odersky explains how and why packages and imports have changed in 2.8.
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: September 9, 2010 1:49 PM by
Martin
|
|
The second installment of a series of articles on the latest Scala release, Scala 2.8, Martin Odersky explains how and why packages and imports have changed in 2.8. http://www.artima.com/scalazine/articles/chained_package_clauses_in_scala.htmlWhat's your opinion on Scala's packages and imports scheme?
|
|
|
|
|
First of all, it's good to have such a clear and systematic explanation of packages in Scala 2.8. It seems to be a really confusion topic, e.g. I answered already two questions about this on StackOverflow (and now I added the link to the article).
Second, I like the way it works now: You have the choice what you want to see. I think this helps to use an interconnected group of packages as a kind of module or "superpackage" (together with the possibility to specify package dependent visibility for modifiers).
I have one open question about packages in Scala: They are conceptually very similar to objects (especially after introducing package objects that allow to add independent "stuff" to them). So shouldn't we try to "unify" objects and packages in one or another way? If this is *no* good idea, I'd like to hear the reason, as I have somethime trouble to decide if I should use objects or packages to structure my code.
|
|
|
|
|
> I have one open question about packages in Scala: They are
> conceptually very similar to objects (especially after
> introducing package objects that allow to add independent
> "stuff" to them). So shouldn't we try to "unify" objects
> and packages in one or another way? If this is *no* good
> idea, I'd like to hear the reason, as I have somethime
> trouble to decide if I should use objects or packages to
> structure my code.
Absolutely. In fact, in the internals of the Scala compiler, packages are a special case of objects. And package objects bring packages a step closer to being real objects (this will be covered in another post). The reason packages are not quite the same as objects has to do with Java interop. There's no way we can treat a Java package as a value that we can pass to a function, for instance.
|
|