When extending a trait within a trait, what does 'super' refer to?

Question

I want to to extend a trait within a trait, like this:

  trait NodeTypes {
    trait Node {
      def allNodesHaveThis: Int
    }
  }

  trait ScrumptiousTypes extends NodeTypes {
    trait Node extends super.Node {
      def scrumptiousness: Int
    }
  }

  trait YummyTypes extends NodeTypes {
    trait Node extends super.Node {
      def yumminess: Int
    }
  }

  object Graph extends NodeTypes with ScrumptiousTypes with YummyTypes {
    case class Node() extends super.Node {
      override def allNodesHaveThis = 1
      override def scrumptiousness = 2  // error: ScrumptiousTypes.Node has been disinherited
      override def yumminess = 3
    }
  }

If this works, it would be a nice way of saying “When your Graph inherits from <Whatever>Types, its Node class must provide the methods required by <Whatever>.”

But the Scala 2.11.2 compiler says:

error: method scrumptiousness overrides nothing
      override def scrumptiousness = 2
                   ^

It appears that YummyTypes.Node shadows ScrumptiousTypes.Node, following the usual way that Scala resolves “diamond” inheritance for methods: by type linearization. As I understand things, that should be OK, though, because YummyTypes.Node explicitly extends super.Node, which, by the same type linearization, should refer to ScrumptiousTypes.

What have I misunderstood? Or, what does super.Node refer to—and why?

If you're wondering why I'm doing this, it's so I can mix changes into several traits at once, so the inherited traits interoperate, as explained in this question. In the final Node class (and other classes that it works with), I don't want to explicitly extend from each Node trait: I want to mix in from one "thing" (whatever it is) and get all the mutually consistent changes made to Node and the other traits, all in a bundle. Or, if one trait defines a bunch of extensions to Node, extending from ScrumptiousTypes should make all of the Node-extensions contain a scrumptiousness member, without having to list all the Node-extensions: trait Hypernode extends ScrumptiousTypes.Node, trait ZealousNode extends ScrumptiousTypes.Node, etc.

@ravindra Interesting idea, but I'd prefer not to do that. The idea is that you should be able to mix in the `...Types` traits in any combination that you like. For example, you should be able to require `yumminess` without also requiring `scrumptiousness`, like this: `object Graph extends YummyTypes`. — Ben Kovitz, Nov 21 '15 at 03:34

余杰水 · Answer 1 · 2015-11-23T12:57:59.977

use type also fix the issue

trait NodeTypes {

  trait Node {
    def allNodesHaveThis: Int
  }

}

trait ScrumptiousTypes extends NodeTypes {

  trait Node extends super.Node {
    def scrumptiousness: Int
  }

  type ScrumptiousTypesNode = this.Node
}

trait YummyTypes extends NodeTypes {

  trait Node extends super.Node {
    def yumminess: Int
  }

  type YummyTypesNode = this.Node
}

object Graph extends NodeTypes with ScrumptiousTypes with YummyTypes {

  case class Node() extends ScrumptiousTypesNode with YummyTypesNode {
    override def allNodesHaveThis = 1

    override def scrumptiousness = 2

    override def yumminess = 3
  }

}

------v2------- use object contain to Node , but since path depend it is not a good idea , and maybe It will be problems

trait NodeTypes {

  trait Node {
    def allNodesHaveThis: Int
  }

}

object NodeTypes extends NodeTypes

trait ScrumptiousTypes extends NodeTypes {

  trait Node {
    def scrumptiousness: Int
  }

  type ScrumptiousTypesNode = this.Node
}

object ScrumptiousTypes extends ScrumptiousTypes

trait YummyTypes extends NodeTypes {

  trait Node {
    def yumminess: Int
  }

  type YummyTypesNode = this.Node
}

object YummyTypes extends YummyTypes

trait Nodes {

  trait Nodes extends NodeTypes.Node with  YummyTypes.Node with ScrumptiousTypes.Node

}


object Graph extends  Nodes {

  case class Nodes() extends super.Nodes {
    override def yumminess: Int = 1
//
    override def scrumptiousness: Int = 2

    override def allNodesHaveThis: Int = 3
  }

}

Thanks. I'm using an approach like this right now. It's error-prone, though, because you have to say almost the same thing twice. How could I make it so that inheriting from the `...Types` traits would redefine `Node` (inside the `Graph` object)? — Ben Kovitz, Nov 22 '15 at 15:42
look at version2 but i do not recommended use it , use type is better usually,i think — 余杰水, Nov 23 '15 at 13:02
I posted [another question](http://stackoverflow.com/q/33965799/1393162) about this, explicitly asking for a workaround. Hopefully that makes clearer what I'm trying to do. — Ben Kovitz, Nov 28 '15 at 23:37

score 3 · Answer 2 · edited May 23 '17 at 12:10

3

This is because of class lineraization. See Spec.

Explanation

Let C be a class with template C1 with ... with Cn. Then lineraization is concatenation of elements from Cn to C1, replacing all identical elements to left. Here elements include var, val, def, traits, object.

If you want to see the order of linearization, use

import scala.reflect.runtime.universe._
val tpe = typeOf[scala.collection.immutable.List[_]]
tpe.baseClasses foreach { s => println(s.fullName) }

In your case, if you change the order from ScrumptiousTypes with YummyTypes to YummyTypes with ScrumptiousTypes, then error will be on method yumminess.

An alternate to @余杰水 is to extend inner class like,

case class Node() extends super[ScrumptiousTypes].Node with super[YummyTypes].Node

edited May 23 '17 at 12:10

Community

1
1

answered Nov 21 '15 at 10:02

Johny T Koshy

3,857
2
23
40

Thanks—i didn't know about the `super[_traitname_]` syntax. But why doesn't `super.Node` inside `YummyTypes` refer to `ScrumptiousTypes.Node` in `object Graph extends ScrumptiousTypes with YummyTypes`? As I understand linearization (perhaps wrongly), that's how it normally works. – Ben Kovitz Nov 22 '15 at 15:36
Indeed! But why? When referring to a var, val, or def, `super` refers to the actual superclass when the trait is mixed into a real object, not to the superclass mentioned in the trait's definition. – Ben Kovitz Nov 22 '15 at 15:46
The behavior is mentioned in the spec. I have linked it. – Johny T Koshy Nov 22 '15 at 15:58
I just posted the details of my reading of the spec [here](http://stackoverflow.com/a/33859618/1393162). If you have enough time to read through it, please see if you can tell where I went wrong. Maybe there's some relevant part of the spec that I overlooked. – Ben Kovitz Nov 22 '15 at 20:14

score 1 · Answer 3 · edited Jun 20 '20 at 09:12

This isn't meant to be an answer. It's just quotations from and interpretations of the spec, which are too long to fit readably into comments (prompted by johny's answer). I'm spelling out my interpretations so you might be able to spot where I went wrong. Maybe this will lead to an explanation or to a way to chain extensions of traits within traits (or to a bug report in the unlikely event that my interpretation turns out to be right).

Relevant passages from the Scala spec

§6.5 This and Super: A reference super.m refers statically to a method or type m in the least proper supertype of the innermost template containing the reference. It evaluates to the member m′ in the actual supertype of that template which is equal to m or which overrides m.

The big question is: What does the spec say that super.Node inside YummyTypes refers to? To find out, we'll need to know the definitions of the spec-specific terms used above:

§5.1 Templates: A template defines the type signature, behavior and initial state of a trait or class of objects or of a single object.

So, a template is what we'd ordinarily call an object, class, or trait definition.

§5.4 Traits: A trait is a class that is meant to be added to some other class as a mixin. … The least proper supertype of a template is the class type or compound type consisting of all its parent class types.

§5.1.2 Class Linearization: Let C be a class with template C₁ with ... with C_n. The linearization of C, L(C), is defined as follows:

L(C) = C,L(C_n) +⃗ … +⃗ L(C₁)

Here +⃗ denotes concatenation where elements of the right operand replace identical elements of the left operand.

I take this to mean that the linearization is a sequence of classes, which you get by starting with the class being defined and then reading the with types from right to left. When two classes in the linearization define a member or type with the same name (an “element”), the class that comes first “wins”.

So, the linearization of Graph should be Graph,YummyTypes,ScrumptiousTypes,NodeTypes, followed by standard stuff like Any. Indeed, this is confirmed when I modify Graph like this:

  object Graph extends ScrumptiousTypes with YummyTypes {
    case class Node() extends super.Node { /* … */ }

    typeOf[Graph.type].baseClasses foreach { s => println(s.fullName) }
  }

which produces:

Graph
YummyTypes
ScrumptiousTypes
NodeTypes
java.lang.Object
scala.Any

§5.4 Traits: Assume a trait D defines some aspect of an instance x of type C (i.e. D is a base class of C). Then the actual supertype of D in x is the compound type consisting of all the base classes in L(C) that succeed D. The actual supertype gives the context for resolving a super reference in a trait. Note that the actual supertype depends on the type to which the trait is added in a mixin composition; it is not statically known at the time the trait is defined.

I take this to mean that the "actual" least proper supertype of a mixed-in trait is determined by the type of the actual object that the trait is mixed into (Graph in my example), not necessarily a supertype that the trait's definition explicitly extends (NodeTypes in my example).

Conclusion

So, it would appear that the actual supertype of YummyTypes in Graph should be ScrumptiousTypes. And so, the actual supertype of YummyTypes.Node in Graph should be ScrumptiousTypes.Node.

However, adding this line to Graph:

typeOf[Node].baseClasses foreach { s => println(s.fullName) }

produces:

Graph.Node
scala.Serializable
java.io.Serializable
scala.Product
scala.Equals
YummyTypes.Node
NodeTypes.Node
java.lang.Object
scala.Any

ScrumptiousTypes.Node is missing. Apparently, inside YummyTypes, super.Node does not refer to Node in YummyTypes' actual least proper supertype.

However, if I add:

abstract override def text = super.text + " ScrumptiousTypes" // in ScrumptiousTypes 
abstract override def text = super.text + " YummyTypes"       // in YummyTypes

printing text in Graph produces:

 ScrumptiousTypes YummyTypes

demonstrating that inside YummyTypes in Graph, super.text does refer to ScrumptiousTypes.text!

great research here -- wondering if this is really better suited as an addition to the original question? (or perhaps a new question) — Imran Rashid, Dec 01 '15 at 19:11
@ImranRashid I was afraid it would make the question so long that no one would want to read it. However, over the past week, my concern has shifted from "what's going on here?" to "is this a compiler bug or not?" I'll think about it. :) — Ben Kovitz, Dec 01 '15 at 23:21

When extending a trait within a trait, what does 'super' refer to?

3 Answers3

Relevant passages from the Scala spec

Conclusion

Linked