RE: [opengoop] Virtual Methods (Abstraction)

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

Jean-Pierre,

The example that I posted to the "Data Type Inheritance Cluster" page =
won't
work.  In order to work the class data should be in its own cluster.  I
believe that the structure needs to look like the following:

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

Instead of:

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

I'm sure you meant that "base data" and "child data" are in fact =
clusters,
but I didn't interpret it that way initially.  Having class data in a
cluster separate from the variant is necessary for a descendant to link =
to
an ancestor's data store (rather than duplicating it).

I have posted a new "Example - Data Type Inheritance Cluster Coercion" =
at:
<http://www.openg.org/tiki/tiki-index.php?page=3DData+Type+Inheritance+Cl=
uster
>

This new example uses a class hierarchy from an OOP example (sent to me
privately by Niels Harre), which graphs geometric objects to a picture
control.

-Jim

> -----Original Message-----
> From: ope...@li...=20
> [mailto:ope...@li...]=20
> On Behalf Of Jean-Pierre Drolet
> Sent: Saturday, October 11, 2003 9:47 PM
> To: ope...@li...
> Subject: Re: [opengoop] Virtual Methods (Abstraction)
>=20
>=20
> Jim and All,
>=20
> I have few remarks regarding the material that Jim recently posted.
>=20
> About the example (EXAMPLE-OpenGOOP_inheritance.vi), an=20
> important point to notice in this scheme is that the creation=20
> and access to object data is made by the instanciated child=20
> class (subclass in the example). The child class does know=20
> about its immediate parent data type so it provides methods=20
> for its parent access the object data. Therefore in=20
> principle, the parent class can be used
> independently of the object storage method used by its child.=20
>   "Class Get Data as Ancestor.vi" and "Class Set Data as Ancestor.vi"
> provide the necessary interface. That gives very modular=20
> design. If one want to change how object data is stored,=20
> instanciated and accessed, the VIs needed to be changed are=20
> those few located in <class>\core\Data Access\utils. Of=20
> course, OpenGOOP should provide templates for data=20
> access/storage like reentrant LV2 globals, but the design is=20
> not strongly linked to the access/storage method.
>=20
> In the example, object data is stored in controls of a=20
> template VI and the refnum is that of the front panel=20
> control. The VI to check if an object is valid, "Object=20
> Refnum is valid.vi" simply checks if the object refum is a=20
> valid control refnum. In order for this VI to be independant=20
> of the storage method, this VI would need to be a virtual=20
> method and call the actual "<class> Object Refnum is=20
> valid.vi" to check for the validity of an object. This=20
> example is not completely independant of the storage method yet.
>=20
> About the storage of object data in FP control and using=20
> control refnums as object refnums, I would say that I didn't=20
> originally implemented the technique like in the posted=20
> example. First I designed an example using FP Controls=20
> (embedded clusters) for data storage. When an ancestor needed=20
> to access the data of the object, it did dig into the control=20
> structure to find the cluster subcontrol related to its class=20
> and then access data using value property of the sub control.=20
> This worked very well and is very natural in LabVIEW. Tthe=20
> serious drawback is that FP Control data access thru value=20
> property is slow and blocked when the user interface is busy=20
> (in menus or modal windows). The technique is interesting but=20
> of little value for real applications. After, I modified that=20
> first example to make data access virtual, but keeping the FP=20
> Control storage technique.
>=20
> As I wrote above, OpenGOOP should provide object=20
> creation/access based on reentrant LV2 globals. Having=20
> embedded clusters (child datatype is a cluster of its=20
> specific added data + cluster of its immediate parent) makes=20
> the automatic (wizard) creation of a child class from a=20
> parent class and templates more straightforward. This also=20
> has the advantage that all is always strictly typed (no use=20
> of variants).
>=20
> I would like to propose another option for object datatype=20
> inheritance similar to class type inheritance refnums. Let=20
> the generic/root data type be a variant. The child datatype=20
> is constructed by replacing the variant in its parent by a=20
> cluster including its class data plus a variant (for added=20
> child data). Then we have:
>=20
> object:  variant
> base: {base data, variant}
> child: {base data, {child data, variant}}.
> and so on
>=20
> Like class type inheritance refnums, child datatype will=20
> coerce (upcast) to parent datatype but not the reverse. If=20
> data is accessible as a variant (root data), all classes in=20
> the lineage can explicitely downcast the data to its class=20
> data using "Variant to Data" with error detection at run=20
> time. This would considerably ease the data access (the root=20
> object can create the dataspace (a variant for everybody) and=20
> no dynamic call to ancestor to get the data.
>=20
> I'll let you think about this for the moment....
>=20
> Jean-Pierre
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> ----- Message d'origine -----=20
> De : "Jim Kring" <ji...@ji...>
> =C0 : "OpenGToolkit-Developers"=20
> <ope...@li...>
> Envoy=E9 : 11 octobre, 2003 18:21
> Objet : [opengoop] Virtual Methods (Abstraction)
>=20
>=20
> Hello All,
>=20
> I have just posted the following to the "OpenG Fwk: OpenGOOP=20
> Inheritance Feasibility" page (link below).  Some portions of=20
> it include or relate to a private email I received from=20
> Jean-Pierre Drolet on Tue 7/8/2003.  I am soliciting comments=20
> and questions from anyone who is interested.
>=20
> <http://openg.org/tiki/tiki-index.php?page=3DOpenG+Fwk%3A%20Open
> GOOP%20Inherit
> ance%20Feasibility>
>=20
> Cheers,
>=20
> -Jim
>=20
>=20
> -=3D Virtual Methods =3D-
>=20
> __Intro:__
> A Virtual Method is one which may be overrided by a=20
> descendant class.  A Virtual Method VI is created from a=20
> special Virtual Method template, that has the ability to look=20
> for and dynamically execute descendent class implimentations=20
> of the method, or else call its own implimentation of the=20
> method.  Descendents can override a Virtual Method by=20
> implimenting a VI of the same name and connector pane=20
> (including the ancestor's refnum type). Users of a class,=20
> make all calls to the Virtual Method, rather than a=20
> descendent implimentations so that the user's code can be=20
> used by future descendents.
>=20
> __Overriding Virtual Methods:__
> A Virtual Method is a method that is allowed to be overridden=20
> by descendents.  When a Virtual Method is called, it=20
> dynamically calls the method implimentation of the youngest=20
> descendant to impliment the method. If no descendant=20
> impliments the method, the Virtual Method calls its own=20
> implimentation (via case structure switch).  Because the=20
> Virtual Method callins a descendant's implimentation=20
> dynamically, the connector pane of the descendants' methods=20
> must be explicitly known to the Virtual Method at the time of=20
> its declaration (creation).  Therefore, all descendants'=20
> implementations must have the same connector pane as the=20
> Virtual Method, since the Virtual Method knows its own=20
> connector pane. This connector pane typing requirement also=20
> means that the object refnum type on the descendents'=20
> implimentations must be that of the ancestor that declares=20
> Virtual Method.
>=20
> __Extending Virtual Methods:__
> Rather than completely overriding a Virtual Method, a=20
> descendent may choose to extend it by statically calling the=20
> Virtual Method within the descendants implimentation.  It=20
> seems that a descendant implimentation of a Virtual Method=20
> may choose to statically call __any__ ancestor's=20
> implimentation of the method, and not just the Virtual=20
> Method.  In this way, each time a Virtual method is overrided=20
> it may be extended incrementally.  If each descendant could=20
> only call the Virtual Method, they would have to rewrite all=20
> the extensions added by a elder descendant.  Having the=20
> option to statically call any ancestors implimentation also=20
> opens up the possibility to revert/undo to a previously=20
> implimented extension to the method.
>=20
> __A Simple Example:__
> Car is a Vehicle (is an Object).
>=20
> Vehicle declares the virtual method Accellerate.  Car=20
> impliments Accellerate, which statically calls Vehicle Accelerate.
>=20
> A developer wishing to accelerate the Car would call Vehicle=20
> Accelerate on the Car Refnum.  The call chain would look like this:
>=20
> (1) Vehicle Accelerate >>dynamic>> (2) Car Accelerate=20
> >>static>> (3) Vehicle Accelerate
>=20
> Notes:
> (1) Vehicle Accelerate sees that it is passed a Car Refnum=20
> (and is not in its own call chain - see 3), so it dynamically=20
> calls Car Accelerate.
> (2) Car Accelerate impliments some extensions and statically=20
> calls Vehicle Accelerate.
> (3) Vehicle Accelerate sees that it is in its own call chain=20
> and therefore runs its class implimentation, rather than=20
> dynamically calling a descendant implimentation.  The=20
> recursive call chain, A dynamically calls B dynamically calls=20
> A, is not allowed in LabVIEW; however, A dynamically calls B=20
> statically calls A, is allowed.
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.=20
> SourceForge.net hosts over 70,000 Open Source Projects. See=20
> the people who have HELPED US provide better services: Click=20
> here: http://sourceforge.net/supporters.php
> _______________________________________________
> OpenGToolkit-Developers mailing list=20
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.=20
> SourceForge.net hosts over 70,000 Open Source Projects. See=20
> the people who have HELPED US provide better services: Click=20
> here: http://sourceforge.net/supporters.php
> _______________________________________________
> OpenGToolkit-Developers mailing list=20
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers
>=20