Take the 2-minute tour ×

in scala, i have a base class and a number of child classes. without adding code to a child class or changing the instantiation of a child class, i would like the base class to be able to call some code both before and after the child constructor is executed. before is easy since the base class constructor is called before the child's, but i don't see a way to handle the after case. as a bit of example code:

class A {
  // do some stuff before child constructor is called
  // ...

  // do some other stuff after child constructor is called
  // this could be a method or inline in the constructor, doesn't matter.

class B extends A { // stuff happens in between }

class C extends A { // stuff happens in between }

val b = new B // everything happens inside, no other method call needed

is this behavior possible? thanks.

share|improve this question
add comment

2 Answers

up vote 4 down vote accepted

If you use Scala 2.9, you can arrange something like this:

class A { 
class B extends A with DelayedInit {
  private[this] var count = 0
  def delayedInit(x: => Unit) {
    count += 1
    if (count==2) { println("There") }
class C extends B { println("Ho") }
class D extends C { println("Ha") }

This takes advantage of the new DelayedInit trait which sends delayed constructors from the current and all child classes to a delayedInit method. Unfortunately, since there is not a termination signal, you're limited to skipping a single constructor. So for C, we get:

scala> new C

where the "There" block has magically appeared after the "Ho" block from C. Unfortunately if you extend C, the new initialization happens last:

scala> new D

(You don't really need A there...I just put it there to illustrate what happens with superclasses.)

share|improve this answer
Was this the intended usage of DelayedInit? It's scary! –  huynhjl May 21 '11 at 4:45
@huynhjl - Not really, as far as I can tell. If it was the intended usage, I would have expected the single method to be split into two (one to register the constructor and one to execute when all were registered) or to have some other mechanism to determine the end of the list. I think it was intended for use in classes that always use a common method--like main or run or act--so that you could put the code to execute in as if it were the constructor. You then still call main or act or whatever, which the superclass defines to run through all child constructors. –  Rex Kerr May 21 '11 at 4:48
Oh good. I get a feel for what it can be used for, now. –  huynhjl May 21 '11 at 4:52
@rex this is really interesting, i'm trying to figure out how to make this work in a way that always wraps the last one no matter how many subclasses there are. that seems potentially impossible in the way that you pointed out though. –  Heinrich Schmetterling May 21 '11 at 6:20
@rex the upside is it appears that there's nothing stopping this from wrapping all invocations past a certain depth though. –  Heinrich Schmetterling May 21 '11 at 6:22
show 1 more comment

An 'end of concrete class' callback is possible, the code below outputs :

end of the worlds !

trait A extends DelayedInit {

  def delayedInit(body: => Unit) = {
    println("end of the worlds !")

trait B extends A { println("hello") }
trait C extends B { println("world1") }
trait D extends C { println("world2") }

object Zozo extends  D {
share|improve this answer
add comment

Your Answer


