site/inheritance.html

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-type" content="text/html;charset=UTF-8" />
<title>Inheritance &middot; Crafting Interpreters</title>

<!-- Tell mobile browsers we're optimized for them and they don't need to crop
     the viewport. -->
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<link rel="stylesheet" type="text/css" href="style.css" />

<!-- Oh, God, Source Code Pro is so beautiful it makes me want to cry. -->
<link href='https://fonts.googleapis.com/css?family=Source+Code+Pro:400|Source+Sans+Pro:300,400,600' rel='stylesheet' type='text/css'>

<link rel="icon" type="image/png" href="image/favicon.png" />
<script src="jquery-3.4.1.min.js"></script>
<script src="script.js"></script>

<!-- Google analytics -->
<script>
  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
  })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');

  ga('create', 'UA-42804721-2', 'auto');
  ga('send', 'pageview');
</script>

</head>
<body id="top">

<!-- <div class="scrim"></div> -->
<nav class="wide">
  <a href="/"><img src="image/logotype.png" title="Crafting Interpreters"></a>
  <div class="contents">
<h3><a href="#top">Inheritance<small>13</small></a></h3>

<ul>
    <li><a href="#superclasses-and-subclasses"><small>13.1</small> Superclasses and Subclasses</a></li>
    <li><a href="#inheriting-methods"><small>13.2</small> Inheriting Methods</a></li>
    <li><a href="#calling-superclass-methods"><small>13.3</small> Calling Superclass Methods</a></li>
    <li><a href="#conclusion"><small>13.4</small> Conclusion</a></li>
    <li class="divider"></li>
    <li class="end-part"><a href="#challenges">Challenges</a></li>
</ul>


<div class="prev-next">
    <a href="classes.html" title="Classes" class="left">&larr;&nbsp;Previous</a>
    <a href="a-tree-walk-interpreter.html" title="A Tree-Walk Interpreter">&uarr;&nbsp;Up</a>
    <a href="a-bytecode-virtual-machine.html" title="A Bytecode Virtual Machine" class="right">Next&nbsp;&rarr;</a>
</div>  </div>
</nav>

<nav class="narrow">
<a href="/"><img src="image/logotype.png" title="Crafting Interpreters"></a>
<a href="classes.html" title="Classes" class="prev">←</a>
<a href="a-bytecode-virtual-machine.html" title="A Bytecode Virtual Machine" class="next">→</a>
</nav>

<div class="page">
<div class="nav-wrapper">
<nav class="floating">
  <a href="/"><img src="image/logotype.png" title="Crafting Interpreters"></a>
  <div class="expandable">
<h3><a href="#top">Inheritance<small>13</small></a></h3>

<ul>
    <li><a href="#superclasses-and-subclasses"><small>13.1</small> Superclasses and Subclasses</a></li>
    <li><a href="#inheriting-methods"><small>13.2</small> Inheriting Methods</a></li>
    <li><a href="#calling-superclass-methods"><small>13.3</small> Calling Superclass Methods</a></li>
    <li><a href="#conclusion"><small>13.4</small> Conclusion</a></li>
    <li class="divider"></li>
    <li class="end-part"><a href="#challenges">Challenges</a></li>
</ul>


<div class="prev-next">
    <a href="classes.html" title="Classes" class="left">&larr;&nbsp;Previous</a>
    <a href="a-tree-walk-interpreter.html" title="A Tree-Walk Interpreter">&uarr;&nbsp;Up</a>
    <a href="a-bytecode-virtual-machine.html" title="A Bytecode Virtual Machine" class="right">Next&nbsp;&rarr;</a>
</div>  </div>
  <a id="expand-nav">≡</a>
</nav>
</div>

<article class="chapter">

  <div class="number">13</div>
  <h1>Inheritance</h1>

<blockquote>
<p>Once we were blobs in the sea, and then fishes, and then lizards and rats and
then monkeys, and hundreds of things in between. This hand was once a fin,
this hand once had claws! In my human mouth I have the pointy teeth of a wolf
and the chisel teeth of a rabbit and the grinding teeth of a cow! Our blood is
as salty as the sea we used to live in! When we&rsquo;re frightened, the hair on our
skin stands up, just like it did when we had fur. We are history! Everything
we&rsquo;ve ever been on the way to becoming us, we still are.</p>
<p><cite>Terry Pratchett, <em>A Hat Full of Sky</em></cite></p>
</blockquote>
<p>Can you believe it? We&rsquo;ve reached the last chapter of <a href="a-tree-walk-interpreter.html">Part II</a>. We&rsquo;re almost
done with our first Lox interpreter. The <a href="classes.html">previous chapter</a> was a big ball of
intertwined object-orientation features. I couldn&rsquo;t separate those from each
other, but I did manage to untangle one piece. In this chapter, we&rsquo;ll finish
off Lox&rsquo;s class support by adding inheritance.</p>
<p>Inheritance appears in object-oriented languages all the way back to the <span
name="inherited">first</span> one, <a href="https://en.wikipedia.org/wiki/Simula">Simula</a>. Early on, Kristen Nygaard and
Ole-Johan Dahl noticed commonalities across classes in the simulation programs
they wrote. Inheritance gave them a way to reuse the code for those similar
parts.</p>
<aside name="inherited">
<p>You could say all those other languages <em>inherited</em> it from Simula. Hey-ooo!
I&rsquo;ll, uh, see myself out.</p>
</aside>
<h2><a href="#superclasses-and-subclasses" id="superclasses-and-subclasses"><small>13&#8202;.&#8202;1</small>Superclasses and Subclasses</a></h2>
<p>Given that the concept is &ldquo;inheritance&rdquo;, you would hope they would pick a
consistent metaphor and call them &ldquo;parent&rdquo; and &ldquo;child&rdquo; classes, but that would
be too easy. Way back when, C. A. R. Hoare coined the term &ldquo;<span
name="subclass">subclass</span>&rdquo; to refer to a record type that refines another
type. Simula borrowed that term to refer to a <em>class</em> that inherits from
another. I don&rsquo;t think it was until Smalltalk came along that someone flipped
the Latin prefix to get &ldquo;superclass&rdquo; to refer to the other side of the
relationship. From C++, you also hear &ldquo;base&rdquo; and &ldquo;derived&rdquo; classes. I&rsquo;ll mostly
stick with &ldquo;superclass&rdquo; and &ldquo;subclass&rdquo;.</p>
<aside name="subclass">
<p>&ldquo;Super-&rdquo; and &ldquo;sub-&rdquo; mean &ldquo;above&rdquo; and &ldquo;below&rdquo; in Latin, respectively. Picture an
inheritance tree like a family tree with the root at the top<span class="em">&mdash;</span>subclasses are
below their superclasses on the diagram. More generally, &ldquo;sub-&rdquo; refers to things
that refine or are contained by some more general concept. In zoology, a
subclass is a finer categorization of a larger class of living things.</p>
<p>In set theory, a subset is contained by a larger superset which has all of the
elements of the subset and possibly more. Set theory and programming languages
meet each other in type theory. There, you have &ldquo;supertypes&rdquo; and &ldquo;subtypes&rdquo;.</p>
<p>In statically typed object-oriented languages, a subclass is also often a
subtype of its superclass. Say we have a Doughnut superclass and a BostonCream
subclass. Every BostonCream is also an instance of Doughnut, but there may be
doughnut objects that are not BostonCreams (like Crullers).</p>
<p>Think of a type as the set of all values of that type. The set of all Doughnut
instances contains the set of all BostonCream instances since every BostonCream
is also a Doughnut. So BostonCream is a subclass, and a subtype, and its
instances are a subset. It all lines up.</p><img src="image/inheritance/doughnuts.png" alt="Boston cream &lt;: doughnut." />
</aside>
<p>Our first step towards supporting inheritance in Lox is a way to specify a
superclass when declaring a class. There&rsquo;s a lot of variety in syntax for this.
C++ and C# place a <code>:</code> after the subclass&rsquo;s name, followed by the superclass
name. Java uses <code>extends</code> instead of the colon. Python puts the superclass(es)
in parentheses after the class name. Simula puts the superclass&rsquo;s name <em>before</em>
the <code>class</code> keyword.</p>
<p>This late in the game, I&rsquo;d rather not add a new reserved word or token to the
lexer. We don&rsquo;t have <code>extends</code> or even <code>:</code>, so we&rsquo;ll follow Ruby and use a
less-than sign (<code>&lt;</code>).</p>
<div class="codehilite"><pre><span class="k">class</span> <span class="t">Doughnut</span> {
  <span class="c">// General doughnut stuff...</span>
}

<span class="k">class</span> <span class="t">BostonCream</span> &lt; <span class="t">Doughnut</span> {
  <span class="c">// Boston Cream-specific stuff...</span>
}
</pre></div>
<p>To work this into the grammar, we add a new optional clause in our existing
<code>classDecl</code> rule.</p>
<div class="codehilite"><pre><span class="i">classDecl</span>      → <span class="s">&quot;class&quot;</span> <span class="t">IDENTIFIER</span> ( <span class="s">&quot;&lt;&quot;</span> <span class="t">IDENTIFIER</span> )?
                 <span class="s">&quot;{&quot;</span> <span class="i">function</span>* <span class="s">&quot;}&quot;</span> ;
</pre></div>
<p>After the class name, you can have a <code>&lt;</code> followed by the superclass&rsquo;s name. The
superclass clause is optional because you don&rsquo;t <em>have</em> to have a superclass.
Unlike some other object-oriented languages like Java, Lox has no root &ldquo;Object&rdquo;
class that everything inherits from, so when you omit the superclass clause, the
class has <em>no</em> superclass, not even an implicit one.</p>
<p>We want to capture this new syntax in the class declaration&rsquo;s AST node.</p>
<div class="codehilite"><pre class="insert-before">      &quot;Block      : List&lt;Stmt&gt; statements&quot;,
</pre><div class="source-file"><em>tool/GenerateAst.java</em><br>
in <em>main</em>()<br>
replace 1 line</div>
<pre class="insert">      <span class="s">&quot;Class      : Token name, Expr.Variable superclass,&quot;</span> +
                  <span class="s">&quot; List&lt;Stmt.Function&gt; methods&quot;</span>,
</pre><pre class="insert-after">      &quot;Expression : Expr expression&quot;,
</pre></div>
<div class="source-file-narrow"><em>tool/GenerateAst.java</em>, in <em>main</em>(), replace 1 line</div>

<p>You might be surprised that we store the superclass name as an Expr.Variable,
not a Token. The grammar restricts the superclass clause to a single identifier,
but at runtime, that identifier is evaluated as a variable access. Wrapping the
name in an Expr.Variable early on in the parser gives us an object that the
resolver can hang the resolution information off of.</p>
<p>The new parser code follows the grammar directly.</p>
<div class="codehilite"><pre class="insert-before">    Token name = consume(IDENTIFIER, &quot;Expect class name.&quot;);
</pre><div class="source-file"><em>lox/Parser.java</em><br>
in <em>classDeclaration</em>()</div>
<pre class="insert">

    <span class="t">Expr</span>.<span class="t">Variable</span> <span class="i">superclass</span> = <span class="k">null</span>;
    <span class="k">if</span> (<span class="i">match</span>(<span class="i">LESS</span>)) {
      <span class="i">consume</span>(<span class="i">IDENTIFIER</span>, <span class="s">&quot;Expect superclass name.&quot;</span>);
      <span class="i">superclass</span> = <span class="k">new</span> <span class="t">Expr</span>.<span class="t">Variable</span>(<span class="i">previous</span>());
    }

</pre><pre class="insert-after">    consume(LEFT_BRACE, &quot;Expect '{' before class body.&quot;);
</pre></div>
<div class="source-file-narrow"><em>lox/Parser.java</em>, in <em>classDeclaration</em>()</div>

<p>Once we&rsquo;ve (possibly) parsed a superclass declaration, we store it in the AST.</p>
<div class="codehilite"><pre class="insert-before">    consume(RIGHT_BRACE, &quot;Expect '}' after class body.&quot;);

</pre><div class="source-file"><em>lox/Parser.java</em><br>
in <em>classDeclaration</em>()<br>
replace 1 line</div>
<pre class="insert">    <span class="k">return</span> <span class="k">new</span> <span class="t">Stmt</span>.<span class="t">Class</span>(<span class="i">name</span>, <span class="i">superclass</span>, <span class="i">methods</span>);
</pre><pre class="insert-after">  }
</pre></div>
<div class="source-file-narrow"><em>lox/Parser.java</em>, in <em>classDeclaration</em>(), replace 1 line</div>

<p>If we didn&rsquo;t parse a superclass clause, the superclass expression will be
<code>null</code>. We&rsquo;ll have to make sure the later passes check for that. The first of
those is the resolver.</p>
<div class="codehilite"><pre class="insert-before">    define(stmt.name);
</pre><div class="source-file"><em>lox/Resolver.java</em><br>
in <em>visitClassStmt</em>()</div>
<pre class="insert">

    <span class="k">if</span> (<span class="i">stmt</span>.<span class="i">superclass</span> != <span class="k">null</span>) {
      <span class="i">resolve</span>(<span class="i">stmt</span>.<span class="i">superclass</span>);
    }
</pre><pre class="insert-after">

    beginScope();
</pre></div>
<div class="source-file-narrow"><em>lox/Resolver.java</em>, in <em>visitClassStmt</em>()</div>

<p>The class declaration AST node has a new subexpression, so we traverse into and
resolve that. Since classes are usually declared at the top level, the
superclass name will most likely be a global variable, so this doesn&rsquo;t usually
do anything useful. However, Lox allows class declarations even inside blocks,
so it&rsquo;s possible the superclass name refers to a local variable. In that case,
we need to make sure it&rsquo;s resolved.</p>
<p>Because even well-intentioned programmers sometimes write weird code, there&rsquo;s a
silly edge case we need to worry about while we&rsquo;re in here. Take a look at this:</p>
<div class="codehilite"><pre><span class="k">class</span> <span class="t">Oops</span> &lt; <span class="t">Oops</span> {}
</pre></div>
<p>There&rsquo;s no way this will do anything useful, and if we let the runtime try to
run this, it will break the expectation the interpreter has about there not
being cycles in the inheritance chain. The safest thing is to detect this case
statically and report it as an error.</p>
<div class="codehilite"><pre class="insert-before">    define(stmt.name);

</pre><div class="source-file"><em>lox/Resolver.java</em><br>
in <em>visitClassStmt</em>()</div>
<pre class="insert">    <span class="k">if</span> (<span class="i">stmt</span>.<span class="i">superclass</span> != <span class="k">null</span> &amp;&amp;
        <span class="i">stmt</span>.<span class="i">name</span>.<span class="i">lexeme</span>.<span class="i">equals</span>(<span class="i">stmt</span>.<span class="i">superclass</span>.<span class="i">name</span>.<span class="i">lexeme</span>)) {
      <span class="t">Lox</span>.<span class="i">error</span>(<span class="i">stmt</span>.<span class="i">superclass</span>.<span class="i">name</span>,
          <span class="s">&quot;A class can&#39;t inherit from itself.&quot;</span>);
    }

</pre><pre class="insert-after">    if (stmt.superclass != null) {
</pre></div>
<div class="source-file-narrow"><em>lox/Resolver.java</em>, in <em>visitClassStmt</em>()</div>

<p>Assuming the code resolves without error, the AST travels to the interpreter.</p>
<div class="codehilite"><pre class="insert-before">  public Void visitClassStmt(Stmt.Class stmt) {
</pre><div class="source-file"><em>lox/Interpreter.java</em><br>
in <em>visitClassStmt</em>()</div>
<pre class="insert">    <span class="t">Object</span> <span class="i">superclass</span> = <span class="k">null</span>;
    <span class="k">if</span> (<span class="i">stmt</span>.<span class="i">superclass</span> != <span class="k">null</span>) {
      <span class="i">superclass</span> = <span class="i">evaluate</span>(<span class="i">stmt</span>.<span class="i">superclass</span>);
      <span class="k">if</span> (!(<span class="i">superclass</span> <span class="k">instanceof</span> <span class="t">LoxClass</span>)) {
        <span class="k">throw</span> <span class="k">new</span> <span class="t">RuntimeError</span>(<span class="i">stmt</span>.<span class="i">superclass</span>.<span class="i">name</span>,
            <span class="s">&quot;Superclass must be a class.&quot;</span>);
      }
    }

</pre><pre class="insert-after">    environment.define(stmt.name.lexeme, null);
</pre></div>
<div class="source-file-narrow"><em>lox/Interpreter.java</em>, in <em>visitClassStmt</em>()</div>

<p>If the class has a superclass expression, we evaluate it. Since that could
potentially evaluate to some other kind of object, we have to check at runtime
that the thing we want to be the superclass is actually a class. Bad things
would happen if we allowed code like:</p>
<div class="codehilite"><pre><span class="k">var</span> <span class="t">NotAClass</span> = <span class="s">&quot;I am totally not a class&quot;</span>;

<span class="k">class</span> <span class="t">Subclass</span> &lt; <span class="t">NotAClass</span> {} <span class="c">// ?!</span>
</pre></div>
<p>Assuming that check passes, we continue on. Executing a class declaration turns
the syntactic representation of a class<span class="em">&mdash;</span>its AST node<span class="em">&mdash;</span>into its runtime
representation, a LoxClass object. We need to plumb the superclass through to
that too. We pass the superclass to the constructor.</p>
<div class="codehilite"><pre class="insert-before">      methods.put(method.name.lexeme, function);
    }

</pre><div class="source-file"><em>lox/Interpreter.java</em><br>
in <em>visitClassStmt</em>()<br>
replace 1 line</div>
<pre class="insert">    <span class="t">LoxClass</span> <span class="i">klass</span> = <span class="k">new</span> <span class="t">LoxClass</span>(<span class="i">stmt</span>.<span class="i">name</span>.<span class="i">lexeme</span>,
        (<span class="t">LoxClass</span>)<span class="i">superclass</span>, <span class="i">methods</span>);

</pre><pre class="insert-after">    environment.assign(stmt.name, klass);
</pre></div>
<div class="source-file-narrow"><em>lox/Interpreter.java</em>, in <em>visitClassStmt</em>(), replace 1 line</div>

<p>The constructor stores it in a field.</p>
<div class="codehilite"><div class="source-file"><em>lox/LoxClass.java</em><br>
constructor <em>LoxClass</em>()<br>
replace 1 line</div>
<pre class="insert">  <span class="t">LoxClass</span>(<span class="t">String</span> <span class="i">name</span>, <span class="t">LoxClass</span> <span class="i">superclass</span>,
           <span class="t">Map</span>&lt;<span class="t">String</span>, <span class="t">LoxFunction</span>&gt; <span class="i">methods</span>) {
    <span class="k">this</span>.<span class="i">superclass</span> = <span class="i">superclass</span>;
</pre><pre class="insert-after">    this.name = name;
</pre></div>
<div class="source-file-narrow"><em>lox/LoxClass.java</em>, constructor <em>LoxClass</em>(), replace 1 line</div>

<p>Which we declare here:</p>
<div class="codehilite"><pre class="insert-before">  final String name;
</pre><div class="source-file"><em>lox/LoxClass.java</em><br>
in class <em>LoxClass</em></div>
<pre class="insert">  <span class="k">final</span> <span class="t">LoxClass</span> <span class="i">superclass</span>;
</pre><pre class="insert-after">  private final Map&lt;String, LoxFunction&gt; methods;
</pre></div>
<div class="source-file-narrow"><em>lox/LoxClass.java</em>, in class <em>LoxClass</em></div>

<p>With that, we can define classes that are subclasses of other classes. Now, what
does having a superclass actually <em>do?</em></p>
<h2><a href="#inheriting-methods" id="inheriting-methods"><small>13&#8202;.&#8202;2</small>Inheriting Methods</a></h2>
<p>Inheriting from another class means that everything that&rsquo;s <span
name="liskov">true</span> of the superclass should be true, more or less, of the
subclass. In statically typed languages, that carries a lot of implications. The
sub<em>class</em> must also be a sub<em>type</em>, and the memory layout is controlled so that
you can pass an instance of a subclass to a function expecting a superclass and
it can still access the inherited fields correctly.</p>
<aside name="liskov">
<p>A fancier name for this hand-wavey guideline is the <a href="https://en.wikipedia.org/wiki/Liskov_substitution_principle"><em>Liskov substitution
principle</em></a>. Barbara Liskov introduced it in a keynote during the
formative period of object-oriented programming.</p>
</aside>
<p>Lox is a dynamically typed language, so our requirements are much simpler.
Basically, it means that if you can call some method on an instance of the
superclass, you should be able to call that method when given an instance of the
subclass. In other words, methods are inherited from the superclass.</p>
<p>This lines up with one of the goals of inheritance<span class="em">&mdash;</span>to give users a way to
reuse code across classes. Implementing this in our interpreter is
astonishingly easy.</p>
<div class="codehilite"><pre class="insert-before">      return methods.get(name);
    }

</pre><div class="source-file"><em>lox/LoxClass.java</em><br>
in <em>findMethod</em>()</div>
<pre class="insert">    <span class="k">if</span> (<span class="i">superclass</span> != <span class="k">null</span>) {
      <span class="k">return</span> <span class="i">superclass</span>.<span class="i">findMethod</span>(<span class="i">name</span>);
    }

</pre><pre class="insert-after">    return null;
</pre></div>
<div class="source-file-narrow"><em>lox/LoxClass.java</em>, in <em>findMethod</em>()</div>

<p>That&rsquo;s literally all there is to it. When we are looking up a method on an
instance, if we don&rsquo;t find it on the instance&rsquo;s class, we recurse up through the
superclass chain and look there. Give it a try:</p>
<div class="codehilite"><pre><span class="k">class</span> <span class="t">Doughnut</span> {
  <span class="i">cook</span>() {
    <span class="k">print</span> <span class="s">&quot;Fry until golden brown.&quot;</span>;
  }
}

<span class="k">class</span> <span class="t">BostonCream</span> &lt; <span class="t">Doughnut</span> {}

<span class="t">BostonCream</span>().<span class="i">cook</span>();
</pre></div>
<p>There we go, half of our inheritance features are complete with only three lines
of Java code.</p>
<h2><a href="#calling-superclass-methods" id="calling-superclass-methods"><small>13&#8202;.&#8202;3</small>Calling Superclass Methods</a></h2>
<p>In <code>findMethod()</code> we look for a method on the current class <em>before</em> walking up
the superclass chain. If a method with the same name exists in both the subclass
and the superclass, the subclass one takes precedence or <strong>overrides</strong> the
superclass method. Sort of like how variables in inner scopes shadow outer ones.</p>
<p>That&rsquo;s great if the subclass wants to <em>replace</em> some superclass behavior
completely. But, in practice, subclasses often want to <em>refine</em> the superclass&rsquo;s
behavior. They want to do a little work specific to the subclass, but also
execute the original superclass behavior too.</p>
<p>However, since the subclass has overridden the method, there&rsquo;s no way to refer
to the original one. If the subclass method tries to call it by name, it will
just recursively hit its own override. We need a way to say &ldquo;Call this method,
but look for it directly on my superclass and ignore my override&rdquo;. Java uses
<code>super</code> for this, and we&rsquo;ll use that same syntax in Lox. Here is an example:</p>
<div class="codehilite"><pre><span class="k">class</span> <span class="t">Doughnut</span> {
  <span class="i">cook</span>() {
    <span class="k">print</span> <span class="s">&quot;Fry until golden brown.&quot;</span>;
  }
}

<span class="k">class</span> <span class="t">BostonCream</span> &lt; <span class="t">Doughnut</span> {
  <span class="i">cook</span>() {
    <span class="k">super</span>.<span class="i">cook</span>();
    <span class="k">print</span> <span class="s">&quot;Pipe full of custard and coat with chocolate.&quot;</span>;
  }
}

<span class="t">BostonCream</span>().<span class="i">cook</span>();
</pre></div>
<p>If you run this, it should print:</p>
<div class="codehilite"><pre>Fry until golden brown.
Pipe full of custard and coat with chocolate.
</pre></div>
<p>We have a new expression form. The <code>super</code> keyword, followed by a dot and an
identifier, looks for a method with that name. Unlike calls on <code>this</code>, the search
starts at the superclass.</p>
<h3><a href="#syntax" id="syntax"><small>13&#8202;.&#8202;3&#8202;.&#8202;1</small>Syntax</a></h3>
<p>With <code>this</code>, the keyword works sort of like a magic variable, and the expression
is that one lone token. But with <code>super</code>, the subsequent <code>.</code> and property name
are inseparable parts of the <code>super</code> expression. You can&rsquo;t have a bare <code>super</code>
token all by itself.</p>
<div class="codehilite"><pre><span class="k">print</span> <span class="k">super</span>; <span class="c">// Syntax error.</span>
</pre></div>
<p>So the new clause we add to the <code>primary</code> rule in our grammar includes the
property access as well.</p>
<div class="codehilite"><pre><span class="i">primary</span>        → <span class="s">&quot;true&quot;</span> | <span class="s">&quot;false&quot;</span> | <span class="s">&quot;nil&quot;</span> | <span class="s">&quot;this&quot;</span>
               | <span class="t">NUMBER</span> | <span class="t">STRING</span> | <span class="t">IDENTIFIER</span> | <span class="s">&quot;(&quot;</span> <span class="i">expression</span> <span class="s">&quot;)&quot;</span>
               | <span class="s">&quot;super&quot;</span> <span class="s">&quot;.&quot;</span> <span class="t">IDENTIFIER</span> ;
</pre></div>
<p>Typically, a <code>super</code> expression is used for a method call, but, as with regular
methods, the argument list is <em>not</em> part of the expression. Instead, a super
<em>call</em> is a super <em>access</em> followed by a function call. Like other method calls,
you can get a handle to a superclass method and invoke it separately.</p>
<div class="codehilite"><pre><span class="k">var</span> <span class="i">method</span> = <span class="k">super</span>.<span class="i">cook</span>;
<span class="i">method</span>();
</pre></div>
<p>So the <code>super</code> expression itself contains only the token for the <code>super</code> keyword
and the name of the method being looked up. The corresponding <span
name="super-ast">syntax tree node</span> is thus:</p>
<div class="codehilite"><pre class="insert-before">      &quot;Set      : Expr object, Token name, Expr value&quot;,
</pre><div class="source-file"><em>tool/GenerateAst.java</em><br>
in <em>main</em>()</div>
<pre class="insert">      <span class="s">&quot;Super    : Token keyword, Token method&quot;</span>,
</pre><pre class="insert-after">      &quot;This     : Token keyword&quot;,
</pre></div>
<div class="source-file-narrow"><em>tool/GenerateAst.java</em>, in <em>main</em>()</div>

<aside name="super-ast">
<p>The generated code for the new node is in <a href="appendix-ii.html#super-expression">Appendix II</a>.</p>
</aside>
<p>Following the grammar, the new parsing code goes inside our existing <code>primary()</code>
method.</p>
<div class="codehilite"><pre class="insert-before">      return new Expr.Literal(previous().literal);
    }
</pre><div class="source-file"><em>lox/Parser.java</em><br>
in <em>primary</em>()</div>
<pre class="insert">

    <span class="k">if</span> (<span class="i">match</span>(<span class="i">SUPER</span>)) {
      <span class="t">Token</span> <span class="i">keyword</span> = <span class="i">previous</span>();
      <span class="i">consume</span>(<span class="i">DOT</span>, <span class="s">&quot;Expect &#39;.&#39; after &#39;super&#39;.&quot;</span>);
      <span class="t">Token</span> <span class="i">method</span> = <span class="i">consume</span>(<span class="i">IDENTIFIER</span>,
          <span class="s">&quot;Expect superclass method name.&quot;</span>);
      <span class="k">return</span> <span class="k">new</span> <span class="t">Expr</span>.<span class="t">Super</span>(<span class="i">keyword</span>, <span class="i">method</span>);
    }
</pre><pre class="insert-after">

    if (match(THIS)) return new Expr.This(previous());
</pre></div>
<div class="source-file-narrow"><em>lox/Parser.java</em>, in <em>primary</em>()</div>

<p>A leading <code>super</code> keyword tells us we&rsquo;ve hit a <code>super</code> expression. After that we
consume the expected <code>.</code> and method name.</p>
<h3><a href="#semantics" id="semantics"><small>13&#8202;.&#8202;3&#8202;.&#8202;2</small>Semantics</a></h3>
<p>Earlier, I said a <code>super</code> expression starts the method lookup from &ldquo;the
superclass&rdquo;, but <em>which</em> superclass? The naïve answer is the superclass of
<code>this</code>, the object the surrounding method was called on. That coincidentally
produces the right behavior in a lot of cases, but that&rsquo;s not actually correct.
Gaze upon:</p>
<div class="codehilite"><pre><span class="k">class</span> <span class="t">A</span> {
  <span class="i">method</span>() {
    <span class="k">print</span> <span class="s">&quot;A method&quot;</span>;
  }
}

<span class="k">class</span> <span class="t">B</span> &lt; <span class="t">A</span> {
  <span class="i">method</span>() {
    <span class="k">print</span> <span class="s">&quot;B method&quot;</span>;
  }

  <span class="i">test</span>() {
    <span class="k">super</span>.<span class="i">method</span>();
  }
}

<span class="k">class</span> <span class="t">C</span> &lt; <span class="t">B</span> {}

<span class="t">C</span>().<span class="i">test</span>();
</pre></div>
<p>Translate this program to Java, C#, or C++ and it will print &ldquo;A method&rdquo;, which
is what we want Lox to do too. When this program runs, inside the body of
<code>test()</code>, <code>this</code> is an instance of C. The superclass of C is B, but that is
<em>not</em> where the lookup should start. If it did, we would hit B&rsquo;s <code>method()</code>.</p>
<p>Instead, lookup should start on the superclass of <em>the class containing the
<code>super</code> expression</em>. In this case, since <code>test()</code> is defined inside B, the
<code>super</code> expression inside it should start the lookup on <em>B</em>&rsquo;s superclass<span class="em">&mdash;</span>A.</p>
<p><span name="flow"></span></p><img src="image/inheritance/classes.png" alt="The call chain flowing through the classes." />
<aside name="flow">
<p>The execution flow looks something like this:</p>
<ol>
<li>
<p>We call <code>test()</code> on an instance of C.</p>
</li>
<li>
<p>That enters the <code>test()</code> method inherited from B. That calls
<code>super.method()</code>.</p>
</li>
<li>
<p>The superclass of B is A, so that chains to <code>method()</code> on A, and the program
prints &ldquo;A method&rdquo;.</p>
</li>
</ol>
</aside>
<p>Thus, in order to evaluate a <code>super</code> expression, we need access to the
superclass of the class definition surrounding the call. Alack and alas, at the
point in the interpreter where we are executing a <code>super</code> expression, we don&rsquo;t
have that easily available.</p>
<p>We <em>could</em> add a field to LoxFunction to store a reference to the LoxClass that
owns that method. The interpreter would keep a reference to the
currently executing LoxFunction so that we could look it up later when we hit a
<code>super</code> expression. From there, we&rsquo;d get the LoxClass of the method, then its
superclass.</p>
<p>That&rsquo;s a lot of plumbing. In the <a href="classes.html">last chapter</a>, we had a similar problem when
we needed to add support for <code>this</code>. In that case, we used our existing
environment and closure mechanism to store a reference to the current object.
Could we do something similar for storing the superclass<span
name="rhetorical">?</span> Well, I probably wouldn&rsquo;t be talking about it if the
answer was no, so<span class="ellipse">&thinsp;.&thinsp;.&thinsp;.&nbsp;</span>yes.</p>
<aside name="rhetorical">
<p>Does anyone even like rhetorical questions?</p>
</aside>
<p>One important difference is that we bound <code>this</code> when the method was <em>accessed</em>.
The same method can be called on different instances and each needs its own
<code>this</code>. With <code>super</code> expressions, the superclass is a fixed property of the
<em>class declaration itself</em>. Every time you evaluate some <code>super</code> expression, the
superclass is always the same.</p>
<p>That means we can create the environment for the superclass once, when the class
definition is executed. Immediately before we define the methods, we make a new
environment to bind the class&rsquo;s superclass to the name <code>super</code>.</p><img src="image/inheritance/superclass.png" alt="The superclass environment." />
<p>When we create the LoxFunction runtime representation for each method, that is
the environment they will capture in their closure. Later, when a method is
invoked and <code>this</code> is bound, the superclass environment becomes the parent for
the method&rsquo;s environment, like so:</p><img src="image/inheritance/environments.png" alt="The environment chain including the superclass environment." />
<p>That&rsquo;s a lot of machinery, but we&rsquo;ll get through it a step at a time. Before we
can get to creating the environment at runtime, we need to handle the
corresponding scope chain in the resolver.</p>
<div class="codehilite"><pre class="insert-before">      resolve(stmt.superclass);
    }
</pre><div class="source-file"><em>lox/Resolver.java</em><br>
in <em>visitClassStmt</em>()</div>
<pre class="insert">

    <span class="k">if</span> (<span class="i">stmt</span>.<span class="i">superclass</span> != <span class="k">null</span>) {
      <span class="i">beginScope</span>();
      <span class="i">scopes</span>.<span class="i">peek</span>().<span class="i">put</span>(<span class="s">&quot;super&quot;</span>, <span class="k">true</span>);
    }
</pre><pre class="insert-after">

    beginScope();
</pre></div>
<div class="source-file-narrow"><em>lox/Resolver.java</em>, in <em>visitClassStmt</em>()</div>

<p>If the class declaration has a superclass, then we create a new scope
surrounding all of its methods. In that scope, we define the name &ldquo;super&rdquo;. Once
we&rsquo;re done resolving the class&rsquo;s methods, we discard that scope.</p>
<div class="codehilite"><pre class="insert-before">    endScope();

</pre><div class="source-file"><em>lox/Resolver.java</em><br>
in <em>visitClassStmt</em>()</div>
<pre class="insert">    <span class="k">if</span> (<span class="i">stmt</span>.<span class="i">superclass</span> != <span class="k">null</span>) <span class="i">endScope</span>();

</pre><pre class="insert-after">    currentClass = enclosingClass;
</pre></div>
<div class="source-file-narrow"><em>lox/Resolver.java</em>, in <em>visitClassStmt</em>()</div>

<p>It&rsquo;s a minor optimization, but we only create the superclass environment if the
class actually <em>has</em> a superclass. There&rsquo;s no point creating it when there isn&rsquo;t
a superclass since there&rsquo;d be no superclass to store in it anyway.</p>
<p>With &ldquo;super&rdquo; defined in a scope chain, we are able to resolve the <code>super</code>
expression itself.</p>
<div class="codehilite"><div class="source-file"><em>lox/Resolver.java</em><br>
add after <em>visitSetExpr</em>()</div>
<pre>  <span class="a">@Override</span>
  <span class="k">public</span> <span class="t">Void</span> <span class="i">visitSuperExpr</span>(<span class="t">Expr</span>.<span class="t">Super</span> <span class="i">expr</span>) {
    <span class="i">resolveLocal</span>(<span class="i">expr</span>, <span class="i">expr</span>.<span class="i">keyword</span>);
    <span class="k">return</span> <span class="k">null</span>;
  }
</pre></div>
<div class="source-file-narrow"><em>lox/Resolver.java</em>, add after <em>visitSetExpr</em>()</div>

<p>We resolve the <code>super</code> token exactly as if it were a variable. The resolution
stores the number of hops along the environment chain that the interpreter needs
to walk to find the environment where the superclass is stored.</p>
<p>This code is mirrored in the interpreter. When we evaluate a subclass
definition, we create a new environment.</p>
<div class="codehilite"><pre class="insert-before">        throw new RuntimeError(stmt.superclass.name,
            &quot;Superclass must be a class.&quot;);
      }
    }

    environment.define(stmt.name.lexeme, null);
</pre><div class="source-file"><em>lox/Interpreter.java</em><br>
in <em>visitClassStmt</em>()</div>
<pre class="insert">

    <span class="k">if</span> (<span class="i">stmt</span>.<span class="i">superclass</span> != <span class="k">null</span>) {
      <span class="i">environment</span> = <span class="k">new</span> <span class="t">Environment</span>(<span class="i">environment</span>);
      <span class="i">environment</span>.<span class="i">define</span>(<span class="s">&quot;super&quot;</span>, <span class="i">superclass</span>);
    }
</pre><pre class="insert-after">

    Map&lt;String, LoxFunction&gt; methods = new HashMap&lt;&gt;();
</pre></div>
<div class="source-file-narrow"><em>lox/Interpreter.java</em>, in <em>visitClassStmt</em>()</div>

<p>Inside that environment, we store a reference to the superclass<span class="em">&mdash;</span>the actual
LoxClass object for the superclass which we have now that we are in the runtime.
Then we create the LoxFunctions for each method. Those will capture the current
environment<span class="em">&mdash;</span>the one where we just bound &ldquo;super&rdquo;<span class="em">&mdash;</span>as their closure, holding
on to the superclass like we need. Once that&rsquo;s done, we pop the environment.</p>
<div class="codehilite"><pre class="insert-before">    LoxClass klass = new LoxClass(stmt.name.lexeme,
        (LoxClass)superclass, methods);
</pre><div class="source-file"><em>lox/Interpreter.java</em><br>
in <em>visitClassStmt</em>()</div>
<pre class="insert">

    <span class="k">if</span> (<span class="i">superclass</span> != <span class="k">null</span>) {
      <span class="i">environment</span> = <span class="i">environment</span>.<span class="i">enclosing</span>;
    }
</pre><pre class="insert-after">

    environment.assign(stmt.name, klass);
</pre></div>
<div class="source-file-narrow"><em>lox/Interpreter.java</em>, in <em>visitClassStmt</em>()</div>

<p>We&rsquo;re ready to interpret <code>super</code> expressions themselves. There are a few moving
parts, so we&rsquo;ll build this method up in pieces.</p>
<div class="codehilite"><div class="source-file"><em>lox/Interpreter.java</em><br>
add after <em>visitSetExpr</em>()</div>
<pre>  <span class="a">@Override</span>
  <span class="k">public</span> <span class="t">Object</span> <span class="i">visitSuperExpr</span>(<span class="t">Expr</span>.<span class="t">Super</span> <span class="i">expr</span>) {
    <span class="t">int</span> <span class="i">distance</span> = <span class="i">locals</span>.<span class="i">get</span>(<span class="i">expr</span>);
    <span class="t">LoxClass</span> <span class="i">superclass</span> = (<span class="t">LoxClass</span>)<span class="i">environment</span>.<span class="i">getAt</span>(
        <span class="i">distance</span>, <span class="s">&quot;super&quot;</span>);
  }
</pre></div>
<div class="source-file-narrow"><em>lox/Interpreter.java</em>, add after <em>visitSetExpr</em>()</div>

<p>First, the work we&rsquo;ve been leading up to. We look up the surrounding class&rsquo;s
superclass by looking up &ldquo;super&rdquo; in the proper environment.</p>
<p>When we access a method, we also need to bind <code>this</code> to the object the method is
accessed from. In an expression like <code>doughnut.cook</code>, the object is whatever we
get from evaluating <code>doughnut</code>. In a <code>super</code> expression like <code>super.cook</code>, the
current object is implicitly the <em>same</em> current object that we&rsquo;re using. In
other words, <code>this</code>. Even though we are looking up the <em>method</em> on the
superclass, the <em>instance</em> is still <code>this</code>.</p>
<p>Unfortunately, inside the <code>super</code> expression, we don&rsquo;t have a convenient node
for the resolver to hang the number of hops to <code>this</code> on. Fortunately, we do
control the layout of the environment chains. The environment where &ldquo;this&rdquo; is
bound is always right inside the environment where we store &ldquo;super&rdquo;.</p>
<div class="codehilite"><pre class="insert-before">    LoxClass superclass = (LoxClass)environment.getAt(
        distance, &quot;super&quot;);
</pre><div class="source-file"><em>lox/Interpreter.java</em><br>
in <em>visitSuperExpr</em>()</div>
<pre class="insert">

    <span class="t">LoxInstance</span> <span class="i">object</span> = (<span class="t">LoxInstance</span>)<span class="i">environment</span>.<span class="i">getAt</span>(
        <span class="i">distance</span> - <span class="n">1</span>, <span class="s">&quot;this&quot;</span>);
</pre><pre class="insert-after">  }
</pre></div>
<div class="source-file-narrow"><em>lox/Interpreter.java</em>, in <em>visitSuperExpr</em>()</div>

<p>Offsetting the distance by one looks up &ldquo;this&rdquo; in that inner environment. I
admit this isn&rsquo;t the most <span name="elegant">elegant</span> code, but it
works.</p>
<aside name="elegant">
<p>Writing a book that includes every single line of code for a program means I
can&rsquo;t hide the hacks by leaving them as an &ldquo;exercise for the reader&rdquo;.</p>
</aside>
<p>Now we&rsquo;re ready to look up and bind the method, starting at the superclass.</p>
<div class="codehilite"><pre class="insert-before">    LoxInstance object = (LoxInstance)environment.getAt(
        distance - 1, &quot;this&quot;);
</pre><div class="source-file"><em>lox/Interpreter.java</em><br>
in <em>visitSuperExpr</em>()</div>
<pre class="insert">

    <span class="t">LoxFunction</span> <span class="i">method</span> = <span class="i">superclass</span>.<span class="i">findMethod</span>(<span class="i">expr</span>.<span class="i">method</span>.<span class="i">lexeme</span>);
    <span class="k">return</span> <span class="i">method</span>.<span class="i">bind</span>(<span class="i">object</span>);
</pre><pre class="insert-after">  }
</pre></div>
<div class="source-file-narrow"><em>lox/Interpreter.java</em>, in <em>visitSuperExpr</em>()</div>

<p>This is almost exactly like the code for looking up a method of a get
expression, except that we call <code>findMethod()</code> on the superclass instead of on
the class of the current object.</p>
<p>That&rsquo;s basically it. Except, of course, that we might <em>fail</em> to find the method.
So we check for that too.</p>
<div class="codehilite"><pre class="insert-before">

    LoxFunction method = superclass.findMethod(expr.method.lexeme);
</pre><div class="source-file"><em>lox/Interpreter.java</em><br>
in <em>visitSuperExpr</em>()</div>
<pre class="insert">

    <span class="k">if</span> (<span class="i">method</span> == <span class="k">null</span>) {
      <span class="k">throw</span> <span class="k">new</span> <span class="t">RuntimeError</span>(<span class="i">expr</span>.<span class="i">method</span>,
          <span class="s">&quot;Undefined property &#39;&quot;</span> + <span class="i">expr</span>.<span class="i">method</span>.<span class="i">lexeme</span> + <span class="s">&quot;&#39;.&quot;</span>);
    }

</pre><pre class="insert-after">    return method.bind(object);
  }
</pre></div>
<div class="source-file-narrow"><em>lox/Interpreter.java</em>, in <em>visitSuperExpr</em>()</div>

<p>There you have it! Take that BostonCream example earlier and give it a try.
Assuming you and I did everything right, it should fry it first, then stuff it
with cream.</p>
<h3><a href="#invalid-uses-of-super" id="invalid-uses-of-super"><small>13&#8202;.&#8202;3&#8202;.&#8202;3</small>Invalid uses of super</a></h3>
<p>As with previous language features, our implementation does the right thing when
the user writes correct code, but we haven&rsquo;t bulletproofed the intepreter
against bad code. In particular, consider:</p>
<div class="codehilite"><pre><span class="k">class</span> <span class="t">Eclair</span> {
  <span class="i">cook</span>() {
    <span class="k">super</span>.<span class="i">cook</span>();
    <span class="k">print</span> <span class="s">&quot;Pipe full of crème pâtissière.&quot;</span>;
  }
}
</pre></div>
<p>This class has a <code>super</code> expression, but no superclass. At runtime, the code for
evaluating <code>super</code> expressions assumes that &ldquo;super&rdquo; was successfully resolved
and will be found in the environment. That&rsquo;s going to fail here because there is
no surrounding environment for the superclass since there is no superclass. The
JVM will throw an exception and bring our interpreter to its knees.</p>
<p>Heck, there are even simpler broken uses of super:</p>
<div class="codehilite"><pre><span class="k">super</span>.<span class="i">notEvenInAClass</span>();
</pre></div>
<p>We could handle errors like these at runtime by checking to see if the lookup
of &ldquo;super&rdquo; succeeded. But we can tell statically<span class="em">&mdash;</span>just by looking at the
source code<span class="em">&mdash;</span>that Eclair has no superclass and thus no <code>super</code> expression will
work inside it. Likewise, in the second example, we know that the <code>super</code>
expression is not even inside a method body.</p>
<p>Even though Lox is dynamically typed, that doesn&rsquo;t mean we want to defer
<em>everything</em> to runtime. If the user made a mistake, we&rsquo;d like to help them find
it sooner rather than later. So we&rsquo;ll report these errors statically, in the
resolver.</p>
<p>First, we add a new case to the enum we use to keep track of what kind of class
is surrounding the current code being visited.</p>
<div class="codehilite"><pre class="insert-before">    NONE,
</pre><pre class="insert-before">    <span class="i">CLASS</span><span class="insert-comma">,</span>
</pre><div class="source-file"><em>lox/Resolver.java</em><br>
in enum <em>ClassType</em><br>
add <em>&ldquo;,&rdquo;</em> to previous line</div>
<pre class="insert">    <span class="i">SUBCLASS</span>
</pre><pre class="insert-after">  }
</pre></div>
<div class="source-file-narrow"><em>lox/Resolver.java</em>, in enum <em>ClassType</em>, add <em>&ldquo;,&rdquo;</em> to previous line</div>

<p>We&rsquo;ll use that to distinguish when we&rsquo;re inside a class that has a superclass
versus one that doesn&rsquo;t. When we resolve a class declaration, we set that if the
class is a subclass.</p>
<div class="codehilite"><pre class="insert-before">    if (stmt.superclass != null) {
</pre><div class="source-file"><em>lox/Resolver.java</em><br>
in <em>visitClassStmt</em>()</div>
<pre class="insert">      <span class="i">currentClass</span> = <span class="t">ClassType</span>.<span class="i">SUBCLASS</span>;
</pre><pre class="insert-after">      resolve(stmt.superclass);
</pre></div>
<div class="source-file-narrow"><em>lox/Resolver.java</em>, in <em>visitClassStmt</em>()</div>

<p>Then, when we resolve a <code>super</code> expression, we check to see that we are
currently inside a scope where that&rsquo;s allowed.</p>
<div class="codehilite"><pre class="insert-before">  public Void visitSuperExpr(Expr.Super expr) {
</pre><div class="source-file"><em>lox/Resolver.java</em><br>
in <em>visitSuperExpr</em>()</div>
<pre class="insert">    <span class="k">if</span> (<span class="i">currentClass</span> == <span class="t">ClassType</span>.<span class="i">NONE</span>) {
      <span class="t">Lox</span>.<span class="i">error</span>(<span class="i">expr</span>.<span class="i">keyword</span>,
          <span class="s">&quot;Can&#39;t use &#39;super&#39; outside of a class.&quot;</span>);
    } <span class="k">else</span> <span class="k">if</span> (<span class="i">currentClass</span> != <span class="t">ClassType</span>.<span class="i">SUBCLASS</span>) {
      <span class="t">Lox</span>.<span class="i">error</span>(<span class="i">expr</span>.<span class="i">keyword</span>,
          <span class="s">&quot;Can&#39;t use &#39;super&#39; in a class with no superclass.&quot;</span>);
    }

</pre><pre class="insert-after">    resolveLocal(expr, expr.keyword);
</pre></div>
<div class="source-file-narrow"><em>lox/Resolver.java</em>, in <em>visitSuperExpr</em>()</div>

<p>If not<span class="em">&mdash;</span>oopsie!<span class="em">&mdash;</span>the user made a mistake.</p>
<h2><a href="#conclusion" id="conclusion"><small>13&#8202;.&#8202;4</small>Conclusion</a></h2>
<p>We made it! That final bit of error handling is the last chunk of code needed to
complete our Java implementation of Lox. This is a real <span
name="superhero">accomplishment</span> and one you should be proud of. In the
past dozen chapters and a thousand or so lines of code, we have learned and
implemented<span class="ellipse">&thinsp;.&thinsp;.&thinsp;.&nbsp;</span></p>
<ul>
<li><a href="scanning.html">tokens and lexing</a>,</li>
<li><a href="representing-code.html">abstract syntax trees</a>,</li>
<li><a href="parsing-expressions.html">recursive descent parsing</a>,</li>
<li>prefix and infix expressions,</li>
<li>runtime representation of objects,</li>
<li><a href="evaluating-expressions.html">interpreting code using the Visitor pattern</a>,</li>
<li><a href="statements-and-state.html">lexical scope</a>,</li>
<li>environment chains for storing variables,</li>
<li><a href="control-flow.html">control flow</a>,</li>
<li><a href="functions.html">functions with parameters</a>,</li>
<li>closures,</li>
<li><a href="resolving-and-binding.html">static variable resolution and error detection</a>,</li>
<li><a href="classes.html">classes</a>,</li>
<li>constructors,</li>
<li>fields,</li>
<li>methods, and finally,</li>
<li>inheritance.</li>
</ul>
<aside name="superhero"><img src="image/inheritance/superhero.png" alt="You, being your bad self." />
</aside>
<p>We did all of that from scratch, with no external dependencies or magic tools.
Just you and I, our respective text editors, a couple of collection classes in
the Java standard library, and the JVM runtime.</p>
<p>This marks the end of Part II, but not the end of the book. Take a break. Maybe
write a few fun Lox programs and run them in your interpreter. (You may want to
add a few more native methods for things like reading user input.) When you&rsquo;re
refreshed and ready, we&rsquo;ll embark on our <a href="a-bytecode-virtual-machine.html">next adventure</a>.</p>
<div class="challenges">
<h2><a href="#challenges" id="challenges">Challenges</a></h2>
<ol>
<li>
<p>Lox supports only <em>single inheritance</em><span class="em">&mdash;</span>a class may have a single
superclass and that&rsquo;s the only way to reuse methods across classes. Other
languages have explored a variety of ways to more freely reuse and share
capabilities across classes: mixins, traits, multiple inheritance, virtual
inheritance, extension methods, etc.</p>
<p>If you were to add some feature along these lines to Lox, which would you
pick and why? If you&rsquo;re feeling courageous (and you should be at this
point), go ahead and add it.</p>
</li>
<li>
<p>In Lox, as in most other object-oriented languages, when looking up a
method, we start at the bottom of the class hierarchy and work our way up<span class="em">&mdash;</span>a subclass&rsquo;s method is preferred over a superclass&rsquo;s. In order to get to the
superclass method from within an overriding method, you use <code>super</code>.</p>
<p>The language <a href="https://beta.cs.au.dk/">BETA</a> takes the <a href="http://journal.stuffwithstuff.com/2012/12/19/the-impoliteness-of-overriding-methods/">opposite approach</a>. When you call a
method, it starts at the <em>top</em> of the class hierarchy and works <em>down</em>. A
superclass method wins over a subclass method. In order to get to the
subclass method, the superclass method can call <code>inner</code>, which is sort of
like the inverse of <code>super</code>. It chains to the next method down the
hierarchy.</p>
<p>The superclass method controls when and where the subclass is allowed to
refine its behavior. If the superclass method doesn&rsquo;t call <code>inner</code> at all,
then the subclass has no way of overriding or modifying the superclass&rsquo;s
behavior.</p>
<p>Take out Lox&rsquo;s current overriding and <code>super</code> behavior and replace it with
BETA&rsquo;s semantics. In short:</p>
<ul>
<li>
<p>When calling a method on a class, prefer the method <em>highest</em> on the
class&rsquo;s inheritance chain.</p>
</li>
<li>
<p>Inside the body of a method, a call to <code>inner</code> looks for a method with
the same name in the nearest subclass along the inheritance chain
between the class containing the <code>inner</code> and the class of <code>this</code>. If
there is no matching method, the <code>inner</code> call does nothing.</p>
</li>
</ul>
<p>For example:</p>
<div class="codehilite"><pre><span class="k">class</span> <span class="t">Doughnut</span> {
  <span class="i">cook</span>() {
    <span class="k">print</span> <span class="s">&quot;Fry until golden brown.&quot;</span>;
    <span class="i">inner</span>();
    <span class="k">print</span> <span class="s">&quot;Place in a nice box.&quot;</span>;
  }
}

<span class="k">class</span> <span class="t">BostonCream</span> &lt; <span class="t">Doughnut</span> {
  <span class="i">cook</span>() {
    <span class="k">print</span> <span class="s">&quot;Pipe full of custard and coat with chocolate.&quot;</span>;
  }
}

<span class="t">BostonCream</span>().<span class="i">cook</span>();
</pre></div>
<p>This should print:</p>
<div class="codehilite"><pre>Fry until golden brown.
Pipe full of custard and coat with chocolate.
Place in a nice box.
</pre></div>
</li>
<li>
<p>In the chapter where I introduced Lox, <a href="the-lox-language.html#challenges">I challenged you</a> to
come up with a couple of features you think the language is missing. Now
that you know how to build an interpreter, implement one of those features.</p>
</li>
</ol>
</div>

<footer>
<a href="a-bytecode-virtual-machine.html" class="next">
  Next Part: &ldquo;A Bytecode Virtual Machine&rdquo; &rarr;
</a>
Handcrafted by Robert Nystrom&ensp;&mdash;&ensp;<a href="https://github.com/munificent/craftinginterpreters/blob/master/LICENSE" target="_blank">&copy; 2015&hairsp;&ndash;&hairsp;2021</a>
</footer>
</article>

</div>
</body>
</html>