StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<h2>Understanding Scala's capabilities</h2> <p>First, we need to understand the capabilities and limitations of each modularization strategy.</p> <h3>Packages</h3> <p>These work just like in Java. You can use many files to declare different parts of one package, and you can nest many levels deep. This provides maximum flexibility with your layout. However, since the default classloaders expect to only find classes and interfaces in packages, that's all Scala lets you put there. (Classes, traits, and objects.)</p> <h3>Objects</h3> <p>Objects can contain anything--methods, fields, other objects, classes, traits, etc.. Subclasses, traits, and objects are actually their own separate entities with the containing object as a name-mangled prefix (as far as the JVM is concerned). An object must be contained wholly within one file, and although you can nest subclasses arbitrarily deep, it's done via mangling increasingly long names, not adding to the path for the classloader.</p> <h3>Package objects</h3> <p>The problem with only having objects and packages is that you might want a nested structure:</p> <pre><code>scala.xml scala.xml.include scala.xml.include.sax </code></pre> <p>so that you need to use packages (to avoid having one gigantic file and disturbingly long class names). But you also might want</p> <pre><code>import scala.xml._ </code></pre> <p>to make various constants and implicit conversions available to you, so that you need to use an object. <a href="http://www.artima.com/scalazine/articles/package_objects.html" rel="noreferrer">Package objects</a> come to the rescue; they are essentially the same as ordinary objects, but when you say</p> <pre><code>import scala.xml._ </code></pre> <p>you get both everything in the package (<code>scala.xml._</code>) but also everything in the corresponding package object (<code>scala.xml.package</code>).</p> <h2>How to modularize your code</h2> <p>Now that we know how each part works, there are fairly obvious rules for how to organize:</p> <ul> <li>Place related code into a package</li> <li>If there are many related sub-parts, place those into sub-packages</li> <li>If a package requires implicits or constants, put those into the package object for that package</li> <li>If you have a terminal branch of your package hierarchy, it is your choice as to whether it should be an object or a package object. There are a few things that package objects are not allowed to do (though the list is getting smaller all the time--I'm not sure there's anything left except a prohibition against shadowing other names in the package), so a regular object might be a better choice. As long as you're not worried about binary compatibility, it's easy to change your mind later--just change <code>object</code> to <code>package object</code> in most cases.</li> </ul>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload