Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>It is predominately used for <a href="http://en.wikipedia.org/wiki/Dependency_injection" rel="noreferrer">Dependency Injection</a>, such as in the <a href="http://www.cakesolutions.net/teamblogs/2011/12/19/cake-pattern-in-depth" rel="noreferrer">Cake Pattern</a>. There exists a <a href="http://jonasboner.com/real-world-scala-dependency-injection-di/" rel="noreferrer">great article</a> covering many different forms of dependency injection in Scala, including the Cake Pattern. If you Google "Cake Pattern and Scala", you'll get many links, including presentations and videos. For now, here is a link to <a href="https://stackoverflow.com/questions/5172188/understanding-scalas-cake-pattern">another question</a>.</p> <p>Now, as to what is the difference between a self type and extending a trait, that is simple. If you say <code>B extends A</code>, then <code>B</code> <em>is</em> an <code>A</code>. When you use self-types, <code>B</code> <em>requires</em> an <code>A</code>. There are two specific requirements that are created with self-types:</p> <ol> <li>If <code>B</code> is extended, then you're <em>required</em> to mix-in an <code>A</code>.</li> <li>When a concrete class finally extends/mixes-in these traits, some class/trait must implement <code>A</code>.</li> </ol> <p>Consider the following examples:</p> <pre><code>scala&gt; trait User { def name: String } defined trait User scala&gt; trait Tweeter { | user: User =&gt; | def tweet(msg: String) = println(s"$name: $msg") | } defined trait Tweeter scala&gt; trait Wrong extends Tweeter { | def noCanDo = name | } &lt;console&gt;:9: error: illegal inheritance; self-type Wrong does not conform to Tweeter's selftype Tweeter with User trait Wrong extends Tweeter { ^ &lt;console&gt;:10: error: not found: value name def noCanDo = name ^ </code></pre> <p>If <code>Tweeter</code> was a subclass of <code>User</code>, there would be no error. In the code above, we <em>required</em> a <code>User</code> whenever <code>Tweeter</code> is used, however a <code>User</code> wasn't provided to <code>Wrong</code>, so we got an error. Now, with the code above still in scope, consider:</p> <pre><code>scala&gt; trait DummyUser extends User { | override def name: String = "foo" | } defined trait DummyUser scala&gt; trait Right extends Tweeter with User { | val canDo = name | } defined trait Right scala&gt; trait RightAgain extends Tweeter with DummyUser { | val canDo = name | } defined trait RightAgain </code></pre> <p>With <code>Right</code>, the requirement to mix-in a <code>User</code> is satisfied. However, the second requirement mentioned above is not satisfied: the burden of implementing <code>User</code> still remains for classes/traits which extend <code>Right</code>. </p> <p>With <code>RightAgain</code> both requirements are satisfied. A <code>User</code> and an implementation of <code>User</code> are provided. </p> <p>For more practical use cases, please see the links at the start of this answer! But, hopefully now you get it. </p>
 

Querying!

 
Guidance

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