VBA inheritance, analog of super

The usual way to do this in VBA is to have A contain an instance of B as well as having A implement B’s interface, and then delegate calls to the B interface of A to the internal B.

This is old stuff, but see the Visual Studio 6.0 Programmer’s Guide:

http://msdn.microsoft.com/en-us/library/aa716285(VS.60).aspx

There is a chapter on “The Many (Inter)Faces of Code Reuse” that describes this convention:

http://msdn.microsoft.com/en-us/library/aa240846(v=VS.60).aspx

The way MS describes it is:

In addition to implementing abstract
interfaces, you can reuse your code by
implementing the interface of an
ordinary class, and then selectively
delegating to a hidden instance of the
class.

This means that implementation inheritance requires lots of explicit delegation methods. There’s even a chapter subheading: “Doesn’t This Get Tedious?”. Yet another reason why OOP in VBA is a PITA (TM)…

EDIT THAT WON’T FIT IN A COMMENT:

To answer the question you posed in your comment, well, an A is a B. When you make A implement B’s interface, you are essentially saying that you can treat an instance of A as if it is actually of type B. In VBA, the way you do that is by declaring a variable of type B, and then setting it to an instance of A. VBA will know what to do when you call it like a B:

Dim usedAsB as B
Dim anA as A

Set anA = New A
Set usedAsB = anA    'fine since A implements B

usedAsB.something()    'will call B_something() defined in class A

As far as what you see in the debug window, I don’t why it appears that way. And as far as forced delegation, I’m not sure what you mean. VBA automatically dispatches calls to the B interface to the right methods in the A class. If you mean automatically generating the code to inherit B’s implementation in the manner described above, there’s nothing like that I know of for VBA. I think the various “professional” versions of VB6 could do that, but I’ve never used VB6 so I don’t know.

Leave a Comment