Re: [opengoop] Virtual Methods (Abstraction)

[Jean-Pierre D. <jea...@tr...>]

Jim and All,

I have few remarks regarding the material that Jim recently posted.

About the example (EXAMPLE-OpenGOOP_inheritance.vi), an important point t=
o notice in this scheme is that the creation and access to
object data is made by the instanciated child class (subclass in the exam=
ple). The child class does know about its immediate parent
data type so it provides methods for its parent access the object data. T=
herefore in principle, the parent class can be used
independently of the object storage method used by its child.   "Class Ge=
t Data as Ancestor.vi" and "Class Set Data as Ancestor.vi"
provide the necessary interface. That gives very modular design. If one w=
ant to change how object data is stored, instanciated and
accessed, the VIs needed to be changed are those few located in <class>\c=
ore\Data Access\utils. Of course, OpenGOOP should provide
templates for data access/storage like reentrant LV2 globals, but the des=
ign is not strongly linked to the access/storage method.

In the example, object data is stored in controls of a template VI and th=
e refnum is that of the front panel control. The VI to
check if an object is valid, "Object Refnum is valid.vi" simply checks if=
 the object refum is a valid control refnum. In order for
this VI to be independant of the storage method, this VI would need to be=
 a virtual method and call the actual "<class> Object
Refnum is valid.vi" to check for the validity of an object. This example =
is not completely independant of the storage method yet.

About the storage of object data in FP control and using control refnums =
as object refnums, I would say that I didn't originally
implemented the technique like in the posted example. First I designed an=
 example using FP Controls (embedded clusters) for data
storage. When an ancestor needed to access the data of the object, it did=
 dig into the control structure to find the cluster
subcontrol related to its class and then access data using value property=
 of the sub control. This worked very well and is very
natural in LabVIEW. Tthe serious drawback is that FP Control data access =
thru value property is slow and blocked when the user
interface is busy (in menus or modal windows). The technique is interesti=
ng but of little value for real applications. After, I
modified that first example to make data access virtual, but keeping the =
FP Control storage technique.

As I wrote above, OpenGOOP should provide object creation/access based on=
 reentrant LV2 globals. Having embedded clusters (child
datatype is a cluster of its specific added data + cluster of its immedia=
te parent) makes the automatic (wizard) creation of a child
class from a parent class and templates more straightforward. This also h=
as the advantage that all is always strictly typed (no use
of variants).

I would like to propose another option for object datatype inheritance si=
milar to class type inheritance refnums. Let the
generic/root data type be a variant. The child datatype is constructed by=
 replacing the variant in its parent by a cluster including
its class data plus a variant (for added child data). Then we have:

object:  variant
base: {base data, variant}
child: {base data, {child data, variant}}.
and so on

Like class type inheritance refnums, child datatype will coerce (upcast) =
to parent datatype but not the reverse. If data is
accessible as a variant (root data), all classes in the lineage can expli=
citely downcast the data to its class data using "Variant
to Data" with error detection at run time. This would considerably ease t=
he data access (the root object can create the dataspace (a
variant for everybody) and no dynamic call to ancestor to get the data.

I'll let you think about this for the moment....

Jean-Pierre







----- Message d'origine -----=20
De : "Jim Kring" <ji...@ji...>
=C0 : "OpenGToolkit-Developers" <ope...@li...=
e.net>
Envoy=E9 : 11 octobre, 2003 18:21
Objet : [opengoop] Virtual Methods (Abstraction)


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 o=
f
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 th=
e
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 pan=
e
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 choo=
se
to extend it by statically calling the Virtual Method within the descenda=
nts
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 possibilit=
y
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 o=
n
the Car Refnum.  The call chain would look like this:

(1) Vehicle Accelerate >>dynamic>> (2) Car Accelerate >>static>> (3) Vehi=
cle
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 Vehicl=
e
Accelerate.
(3) Vehicle Accelerate sees that it is in its own call chain and therefor=
e
runs its class implimentation, rather than dynamically calling a descenda=
nt
implimentation.  The recursive call chain, A dynamically calls B dynamica=
lly
calls A, is not allowed in LabVIEW; however, A dynamically calls B
statically calls A, is allowed.



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
OpenGToolkit-Developers mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers