This morning: “Surprise!  Want to conduct a job interview?”  I’ve been here a little over 3 months, but um, sure!  “Great.  He’s in the conference room right now.”  Wow, we move quick.

So, without much time to gather my thoughts for good tech-y interview questions, I printed out the resume, and I winged it.  In the middle of the interview, I flipped over his resume, and scribbled out short-hand C# like this:

 1 class A {
 2    public A() {
 3       Console.WriteLine("in A");
 4    }
 5 }
 6 class B : A {
 7    public B() {
 8       Console.WriteLine("in B");
 9    }
10 }
11 class C : B {
12    public C() {
13       Console.WriteLine("in C");
14    }
15 }
16 new C();

I asked, “What does this print out?” You know, see if he knows which order constructor inheritance goes in. I wanted to hear, “in A, in B, in C”, but not “in C, in B, in A”.

I forget exactly what the candidate’s answer was, but it stirred up a bit of discussion, because the three of us interviewing him disagreed on the answer: one of us said it would only print “in C,” because you need to stick : base() on the B and C constructors for the inheritance to work; I agreed with the third interviewer, who said it would print “in A, in B, in C”, because constructor inheritance is automatic (with no-arg constructors). We fudged around it, laughed a bit, and the interview moved on. (Update: here’s the answer.)

Back at my desk, I had to try it out. I didn’t want to bother with a whole Visual Studio .sln and all that nonsense, so I tried it in Ruby:

 1 class A
 2     def initialize
 3         puts "in A"
 4     end
 5 end
 6 class B < A
 7     def initialize
 8         puts "in B"
 9     end
10 end
11 class C < B
12     def initialize
13         puts "in C"
14     end
15 end
16 
17 C.new

And the output is…“in C”! Huh? That can’t be right…I was sure constructors were inherited automatically! Then I realized, of course! I’m working in Ruby, and you have to explicitly call superclass methods, constructors included:

 1 class A
 2     def initialize
 3         super # <- call the superclass' constructor
 4         puts "in A"
 5     end
 6 end
 7 class B < A
 8     def initialize
 9         super # <- call the superclass' constructor
10         puts "in B"
11     end
12 end
13 class C < B
14     def initialize
15         super # <- call the superclass' constructor
16         puts "in C"
17     end
18 end
19 
20 C.new

Stupid Ruby! Did I find a case where C# actually works nicer than Ruby? But then I realized, this also means Ruby lets you change the order of the constructor inheritance: you can go bottom-up, if you want, or even stranger:

 1 class A
 2     def initialize
 3         super
 4         puts "in A"
 5     end
 6 end
 7 class B < A
 8     def initialize
 9         super
10         puts "in B"
11     end
12 end
13 class C < B
14     def initialize
15         puts "in C"
16         super # <- call up the chain AFTER we're done
17     end
18 end
19 
20 C.new

That one prints out “in C, in A, in B”. The nice thing? No rule to memorize, and more control. The down-side? More to type. But given how compact Ruby already is, I think the added control is worth it here. What do you think?


(Update: I eventually did fire up Visual Studio, and the code above printed “in A, in B, in C”, without me typing out : base(). C# inherits constructors automatically, and the superclass constructors run before subclass constructors.)