[opengoop] Virtual Methods (Abstraction)

[Jim K. <ji...@ji...>]

Hello All,

I have just posted the following to the "OpenG Fwk: OpenGOOP Inheritance
Feasibility" page (link below).  Some portions of it include or relate =
to a
private email I received from Jean-Pierre Drolet on Tue 7/8/2003.  I am
soliciting comments and questions from anyone who is interested.

<http://openg.org/tiki/tiki-index.php?page=3DOpenG+Fwk%3A%20OpenGOOP%20In=
herit
ance%20Feasibility>

Cheers,

-Jim


-=3D Virtual Methods =3D-

__Intro:__
A Virtual Method is one which may be overrided by a descendant class.  A
Virtual Method VI is created from a special Virtual Method template, =
that
has the ability to look for and dynamically execute descendent class
implimentations of the method, or else call its own implimentation of =
the
method.  Descendents can override a Virtual Method by implimenting a VI =
of
the same name and connector pane (including the ancestor's refnum type).
Users of a class, make all calls to the Virtual Method, rather than a
descendent implimentations so that the user's code can be used by future
descendents.

__Overriding Virtual Methods:__
A Virtual Method is a method that is allowed to be overridden by
descendents.  When a Virtual Method is called, it dynamically calls the
method implimentation of the youngest descendant to impliment the =
method.
If no descendant impliments the method, the Virtual Method calls its own
implimentation (via case structure switch).  Because the Virtual Method
callins a descendant's implimentation dynamically, the connector pane of =
the
descendants' methods must be explicitly known to the Virtual Method at =
the
time of its declaration (creation).  Therefore, all descendants'
implementations must have the same connector pane as the Virtual Method,
since the Virtual Method knows its own connector pane. This connector =
pane
typing requirement also means that the object refnum type on the
descendents' implimentations must be that of the ancestor that declares
Virtual Method.

__Extending Virtual Methods:__
Rather than completely overriding a Virtual Method, a descendent may =
choose
to extend it by statically calling the Virtual Method within the =
descendants
implimentation.  It seems that a descendant implimentation of a Virtual
Method may choose to statically call __any__ ancestor's implimentation =
of
the method, and not just the Virtual Method.  In this way, each time a
Virtual method is overrided it may be extended incrementally.  If each
descendant could only call the Virtual Method, they would have to =
rewrite
all the extensions added by a elder descendant.  Having the option to
statically call any ancestors implimentation also opens up the =
possibility
to revert/undo to a previously implimented extension to the method.

__A Simple Example:__
Car is a Vehicle (is an Object).

Vehicle declares the virtual method Accellerate.  Car impliments
Accellerate, which statically calls Vehicle Accelerate.

A developer wishing to accelerate the Car would call Vehicle Accelerate =
on
the Car Refnum.  The call chain would look like this:

(1) Vehicle Accelerate >>dynamic>> (2) Car Accelerate >>static>> (3) =
Vehicle
Accelerate

Notes:
(1) Vehicle Accelerate sees that it is passed a Car Refnum (and is not =
in
its own call chain - see 3), so it dynamically calls Car Accelerate.
(2) Car Accelerate impliments some extensions and statically calls =
Vehicle
Accelerate.
(3) Vehicle Accelerate sees that it is in its own call chain and =
therefore
runs its class implimentation, rather than dynamically calling a =
descendant
implimentation.  The recursive call chain, A dynamically calls B =
dynamically
calls A, is not allowed in LabVIEW; however, A dynamically calls B
statically calls A, is allowed.