Why is "abstract override" required not "override" alone in subtrait?

Question

I read the section of Programming in Scala where abstract override is introduced, but I'm still confused by what exactly is signified by the joining of these modifiers. The snippet of code in which these modifiers is used is pasted below:

trait Doubling extends IntQueue {
    abstract override def put(x: Int) { super.put(2 * x) }
}

In particular, I am confused by the purpose of abstract in this case, and why we cannot achieve the expected results simply with the override keyword. If we did not include a call to super, would we need the keyword abstract? Why or why not? I'm looking for a detailed explanation of this keyword combo as it pertains to stackable traits.

The [spec says](//www.scala-lang.org/files/archive/spec/2.13/05-classes-and-objects.html#abstract-override): "Note that the abstract override modifier combination does not influence the concept whether a member is concrete or abstract. A member is abstract if only a declaration is given for it; it is concrete if a full definition is given." What would be a use case for an abstract `abstract override` value member? It certainly doesn't refer to super, it has no initializer (or body, in case of a method). Would it be any different from just an abstract overriding member, omitting the `abstract`? — ByteEater, May 21 '22 at 06:36

WestCoastProjects · Accepted Answer · 2018-02-01T15:30:24.110

The reason is that the base class method is abstract

abstract class IntQueue {
  def get(): Int
  def put(x: Int)
}

If you were to not put abstract on the trait you end up with the explanation you were seeking:

trait Doubling extends IntQueue {
     override def put(x: Int) { super.put(2 * x) }
}
<console>:9: error: method put in class IntQueue is accessed from
 super. It may not be abstract unless it is overridden by a member 
 declared `abstract' and `override'
            override def put(x: Int) { super.put(2 * x) }

So - you would need to mark the method as abstract.

Here is the "other side" of the equation: if the methods do have implementations then it is not necessary to mark the trait's method as abstract:

 abstract class IntQueue {
    import collection.mutable._
        val q  =  Queue[Int]()
      def get(): Int = { q.dequeue() }
      def put(x: Int) = { q.enqueue(x) }
   }

It is now unnecessary to include abstract

 trait Doubling extends IntQueue {
        /* Look Ma! no abstract here ! */   override def put(x: Int) { super.put(2 * x) }
      }
defined trait Doubling

_Thank you_. For some reason I keep seeing stackable trait examples with `abstract override`, but it seems to me that the two concepts are actually separate (though both rely on dynamically bound `super`). — Max, Dec 14 '16 at 16:23

score 10 · Answer 2 · answered May 14 '14 at 05:48

The idea is that it's an incomplete override -- you still want to require the eventually concrete implementation of the trait to provide that method, even though you're modifying that hypothetical method's behavior. In other words, the method you're overriding isn't a full standalone implementation. It gives a similar effect as a method decorator might in Python.

As far as I can reason, a method on a trait is abstract override if and only if it calls super, but it breaks encapsulation to expect the client of the code to inspect the implementation of the method to know it needs a concrete implementation. Therefore, you must mark it abstract override to fully define the interface.

score 3 · Answer 3 · edited Nov 16 '19 at 08:35

A part of late binding in scala traits posts; provides a very clear explanation; provided verbatim bellow (read the full post for more info):

The abstract base class provided an implementation of the requestApproval method. This is good since the leftmost trait calls this method. What happens if the base class’s method is abstract?

abstract class ApprovalRequest {
  def requestApproval()
}

If we change this, we get a rather odd message from the compiler: error: method requestApproval in class ApprovalRequest is accessed from super. It may not be abstract unless it is overridden by a member declared abstract and override The combination of abstract and override tells the compiler that the final implementation of the method will be provided by the class mixing-in the trait. If we add the abstract keyword to the methods, we can no longer use our anonymous implementation of ApprovalRequest. That object can’t be created since the abstract override methods will be looking for an implementation of requestApproval and there isn’t one. Instead we have to create a new class that extends ApprovalRequest and implements requestApproval. We then mix the traits into an instance of that class.

class ApprovalDelegate extends ApprovalRequest {
  override def requestApproval() {
    println("and now we play the waiting game")
  }
}

val adCampaign = new ApprovalDelegate with MarketingApprovalRequest
   with FinanceApprovalRequest with ExecutiveApprovalRequest

Which will now give the output:

requesting approaval from executives
requesting approval from Finance
requesting approval from Marketing
and now we play the waiting game

Why is "abstract override" required not "override" alone in subtrait?

3 Answers3

Linked