opengtoolkit-developers — OpenG Toolkit developers mailing list

Re: [opengoop] "Variant To Data" downcasts Class Type Inheritance Refnums

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

Jim,

In fact you used the technique yourself in "EXAMPLE - Get Obj Info From R=
ef.vi" and that made me post the message about "Class
Downcast to Self.vi". This VI should indeed check if the object is valid =
and return an error for invalid object even if the class
downcast succeeds.

Jean-Pierre


----- Message d'origine -----=20
De : "Jim Kring" <ji...@ji...>
=C0 : <ope...@li...>
Envoy=E9 : 13 octobre, 2003 20:28
Objet : [opengoop] "Variant To Data" downcasts Class Type Inheritance Ref=
nums


> Based on Jean-Pierre's comments about using "Variant to Data" for downc=
asting
> an inheritable data structure, I realized that "Variant to Data" can be=
 used
> for downcasting Class Type Inheritance Refnums (analagous to "To More
> Specific Class" fuction).  It will even output an error at run-time (Er=
ror
> 91, "The data type of the variant is not compatible with the data type =
wired
> to the type input."), if the class information in the variant does not =
match
> the more specific type.  For example, this prevents one from trying to
> Downcast to a class from the classes uncle (Car =3D=3D> DeLorian is OK,=
 but Truck
> =3D=3D> Delorian produces an ERROR).  Adopting this technique means tha=
t a class
> does not have to provide a polymorphic VI for downcasting to each desce=
ndant
> type.  The only downside, is that this method does not rely on the obje=
ct
> reference to check if the object is really of the more specific type.
> However, this check will have to be done in any downstream VI that oper=
ates
> on the more specific type.
>
> -Jim
>
>
> -------------------------------------------------------
> 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

Re: [opengoop] Virtual Methods (Abstraction)

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

Good point, Jim

The variant is used as a placeholder for descendant data but still makes =
this data available for ancestors. Not only the data but
also the data name and data type. That's indeed a big violation of encaps=
ulation ( but great for a generic Read/Write Object to
INI...).

If we can't trust developpers not touching the variant child data ( it mi=
ght be easy to rebundle data with empty or bad variant),
then a solution could be that "Get Object Data.vi" get the class name fro=
m the incoming refnum and returns only the data relevant
for this class (e.g. empty variant). That however adds complexity because=
 the simple "Variant to Data" conversion has to be replaced
with class analysis and variant data manipulation to access data. "Set Ob=
ject Data.vi" would also replace only the data known by the
calling class.

My opinion is that added complexity would cancel the benefits of automati=
c upcasting by coercion and downcasting by "Variant to
Data"

Jean-Pierre


----- Message d'origine -----=20
De : "Jim Kring" <ji...@ji...>
=C0 : <ope...@li...>
Envoy=E9 : 13 octobre, 2003 19:45
Objet : Re: [opengoop] Virtual Methods (Abstraction)


> Jean-Pierre,
>
> Should an OpenGOOP user who is developing a class, be given access to t=
he
> class's ancestors' data, at the bundle/unbundle node?  Some people woul=
d
> consider this to be a violation of encapsulation, since the user can ch=
ange
> ancestor data without going through the public interface defined by the
> ancestor.  This could potentially allow a descentan to break a parent's=
 run-
> time characteristics. If all data in the class hierarchy is not aggrega=
ted,
> then the issue of a class hierarchy data structure is not important.
>
> -Jim
>
>

[opengoop] "Variant To Data" downcasts Class Type Inheritance Refnums

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

Based on Jean-Pierre's comments about using "Variant to Data" for downcasting 
an inheritable data structure, I realized that "Variant to Data" can be used 
for downcasting Class Type Inheritance Refnums (analagous to "To More 
Specific Class" fuction).  It will even output an error at run-time (Error 
91, "The data type of the variant is not compatible with the data type wired 
to the type input."), if the class information in the variant does not match 
the more specific type.  For example, this prevents one from trying to 
Downcast to a class from the classes uncle (Car ==> DeLorian is OK, but Truck 
==> Delorian produces an ERROR).  Adopting this technique means that a class 
does not have to provide a polymorphic VI for downcasting to each descendant 
type.  The only downside, is that this method does not rely on the object 
reference to check if the object is really of the more specific type.  
However, this check will have to be done in any downstream VI that operates 
on the more specific type.

-Jim

Re: [opengoop] Virtual Methods (Abstraction)

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

Jean-Pierre,

Should an OpenGOOP user who is developing a class, be given access to the 
class's ancestors' data, at the bundle/unbundle node?  Some people would 
consider this to be a violation of encapsulation, since the user can change 
ancestor data without going through the public interface defined by the 
ancestor.  This could potentially allow a descentan to break a parent's run-
time characteristics. If all data in the class hierarchy is not aggregated, 
then the issue of a class hierarchy data structure is not important.

-Jim


Jean-Pierre Drolet <jea...@tr...> said:

> Yes Jim,
> 
> In the other scheme of inheritance, the datatype grows outwards e.g. the 
child datatype is constructed as embedded clusters:
> 
> child typedef: {child added data,{parent data}}
> 
> and is linked directly to immediate parent typedef
> 
> In the proposed scheme, the datatype grows inwards e.g. the inner variant 
is replaced with the cluster {{child added data},variant}
> 
> child typedef: {{parent added data},{{child1 added data},{{child added 
data},variant}}}
> 
> then it is not linked directly to immediate parent typedef but to all 
{parent added data} typedefs. We have to create two data
> typedefs for the class, {class added data} and inheritance data typedef.
> 
> I also thought of a simplified, non-embedding approach, provided that we 
limit the number of inheritance levels to say five levels:
> 
> generic object datatype: cluster of 5 variants {variant, variant, variant, 
variant, variant}
> 1st generation object: {{parent data}, variant, variant, variant, variant}
> 2nd generation object: {{parent data}, {child data}, variant, variant, 
variant}
> and so on.
> 
> Thise scheme also preserves the class casting behavior but is limited to a 
fix number of inheritance levels. Objects Refnums could
> also be flattened instead of embedded.
> 
> Jean-Pierre
> 
> 
> ----- Message d'origine ----- 
> De : "Jim Kring" <ji...@ji...>
> À : <ope...@li...>
> Envoyé : 13 octobre, 2003 12:27
> Objet : RE: [opengoop] Virtual Methods (Abstraction)
> 
> 
> Jean-Pierre,
> 
> The problem is that a child is going to replace the variant with its own
> data cluster.  If this variant is contained within the parent's data
> cluster, then the child must either edit or copy the parent's cluster.  But,
> the child is not allowed to edit the parent's cluster (we want the
> possibility of several children), so the only option is to make a copy of
> the parent's cluster.  This means that if the parent changes, we have to
> also replicate the changes in the child's cluster.  We don't want to do
> this, we want to link to the parent's data cluster.  So, we should separate
> the parent's data from the Data Type Inheritance Cluster by means of putting
> the parent's data into its own cluster.
> 
> -Jim
> 
> .net/lists/listinfo/opengtoolkit-developers
> 
> 
> 
> -------------------------------------------------------
> 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
> 



-- 

Re: [opengoop] Virtual Methods (Abstraction)

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

Yes Jim,

In the other scheme of inheritance, the datatype grows outwards e.g. the =
child datatype is constructed as embedded clusters:

child typedef: {child added data,{parent data}}

and is linked directly to immediate parent typedef

In the proposed scheme, the datatype grows inwards e.g. the inner variant=
 is replaced with the cluster {{child added data},variant}

child typedef: {{parent added data},{{child1 added data},{{child added da=
ta},variant}}}

then it is not linked directly to immediate parent typedef but to all {pa=
rent added data} typedefs. We have to create two data
typedefs for the class, {class added data} and inheritance data typedef.

I also thought of a simplified, non-embedding approach, provided that we =
limit the number of inheritance levels to say five levels:

generic object datatype: cluster of 5 variants {variant, variant, variant=
, variant, variant}
1st generation object: {{parent data}, variant, variant, variant, variant=
}
2nd generation object: {{parent data}, {child data}, variant, variant, va=
riant}
and so on.

Thise scheme also preserves the class casting behavior but is limited to =
a fix number of inheritance levels. Objects Refnums could
also be flattened instead of embedded.

Jean-Pierre


----- Message d'origine -----=20
De : "Jim Kring" <ji...@ji...>
=C0 : <ope...@li...>
Envoy=E9 : 13 octobre, 2003 12:27
Objet : RE: [opengoop] Virtual Methods (Abstraction)


Jean-Pierre,

The problem is that a child is going to replace the variant with its own
data cluster.  If this variant is contained within the parent's data
cluster, then the child must either edit or copy the parent's cluster.  B=
ut,
the child is not allowed to edit the parent's cluster (we want the
possibility of several children), so the only option is to make a copy of
the parent's cluster.  This means that if the parent changes, we have to
also replicate the changes in the child's cluster.  We don't want to do
this, we want to link to the parent's data cluster.  So, we should separa=
te
the parent's data from the Data Type Inheritance Cluster by means of putt=
ing
the parent's data into its own cluster.

-Jim

.net/lists/listinfo/opengtoolkit-developers

RE: [opengoop] Virtual Methods (Abstraction)

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

Jean-Pierre,

The problem is that a child is going to replace the variant with its own
data cluster.  If this variant is contained within the parent's data
cluster, then the child must either edit or copy the parent's cluster.  =
But,
the child is not allowed to edit the parent's cluster (we want the
possibility of several children), so the only option is to make a copy =
of
the parent's cluster.  This means that if the parent changes, we have to
also replicate the changes in the child's cluster.  We don't want to do
this, we want to link to the parent's data cluster.  So, we should =
separate
the parent's data from the Data Type Inheritance Cluster by means of =
putting
the parent's data into its own cluster.

-Jim

> -----Original Message-----
> From: ope...@li...=20
> [mailto:ope...@li...]=20
> On Behalf Of Jean-Pierre Drolet
> Sent: Monday, October 13, 2003 8:04 AM
> To: ope...@li...
> Subject: Re: [opengoop] Virtual Methods (Abstraction)
>=20
>=20
> Jim,
>=20
> I did not mean clustered child data. I can't see why it=20
> doesn't work without cluster. What's that link/duplicate thing?
>=20
> Jean-Pierre
>=20
> ----- Message d'origine -----=20
> De : "Jim Kring" <ji...@ji...>
> =C0 : <ope...@li...>
> Envoy=E9 : 13 octobre, 2003 02:58
> Objet : RE: [opengoop] Virtual Methods (Abstraction)
>=20
>=20
> Jean-Pierre,
>=20
> The example that I posted to the "Data Type Inheritance=20
> Cluster" page won't work.  In order to work the class data=20
> should be in its own cluster.  I believe that the structure=20
> needs to look like the following:
>=20
> object:  variant
> base: {{base data}, variant}
> child: {{base data}, {{child data}, variant}}.
> and so on
>=20
> Instead of:
>=20
> > object:  variant
> > base: {base data, variant}
> > child: {base data, {child data, variant}}.
> > and so on
>=20
> I'm sure you meant that "base data" and "child data" are in=20
> fact clusters, but I didn't interpret it that way initially. =20
> Having class data in a cluster separate from the variant is=20
> necessary for a descendant to link to an ancestor's data=20
> store (rather than duplicating it).
>=20
> I have posted a new "Example - Data Type Inheritance Cluster=20
> Coercion" at:=20
> <http://www.openg.org/tiki/tiki-index.php?page=3DData+Type+Inher
itance+Cluster
>

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



-------------------------------------------------------
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

<Class> Downcast to Self.vi in the Example

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

Hi all,

I've just noticed that there is an unecessary level of unbundling/bundling in the VI. The class refnum can be wired to the Type
input of Variant to Data and Object Refnum to the Variant input.

Jean-Pierre

Re: [opengoop] Virtual Methods (Abstraction)

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

Jim,

I did not mean clustered child data. I can't see why it doesn't work with=
out cluster. What's that link/duplicate thing?

Jean-Pierre

----- Message d'origine -----=20
De : "Jim Kring" <ji...@ji...>
=C0 : <ope...@li...>
Envoy=E9 : 13 octobre, 2003 02:58
Objet : RE: [opengoop] Virtual Methods (Abstraction)


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 t=
o
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

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

RE: [opengoop] Virtual Methods (Abstraction)

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

Jean-Pierre,

First, thanks for the summary of the example.  I will add some notes =
from
your email to the page containing the OpenGOOP Inheritance example.

>=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

Yes, it only took a moment to see that this is a very natural solution.  =
I
have created a page for this called "Data Type Inheritance Cluster" and
posted an example VI there that is derived from the Class Type =
Inheritance
Refnum example.  This page is located at:
<http://www.openg.org/tiki/tiki-index.php?page=3DData+Type+Inheritance+Cl=
uster
>

There is also a link to this page from the "OpenG Fwk: OpenGOOP =
Inheritance
Feasibility" page:
<http://www.openg.org/tiki/tiki-index.php?page=3DOpenG+Fwk%3A+OpenGOOP+In=
herit
ance+Feasibility>

-Jim

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...urceforg=
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

[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.

Re: [opengoop] Inheritance Nomenclature

[PJ M <pjm...@ya...>]

Jim,
 
>I propose that we adopt the parent/child and ancestor/descendant
>nomenclatures for OpenGOOP Inheritance.
 
I could not agree more
 
PJM

Jim Kring <ji...@ji...> wrote:
Hello all,

For describing inheritance, OOP has many nomenclatures. For example:

parent class - superclass (smalltalk), base class (C++), and ancestor class

child class - subclass (smalltalk), derived class (C++), and descendant
class

For OpenGOOP Inheritance, I think that we should adopt a single
nomenclature. We should consider the fact that G programmers often do not
come from a CS background (I don't :-) and so I favor the parent/child and
ancestor/descendent nomenclatures, rather than those of C++ and smalltalk.
In fact, usage of parent/child and ancestor/descendant nomenclatures are not
mutually exclusive, since parent, grandparent, greatgrandparent, etc. are
specific ancestors, and child, grandchild, and greatgrandchild are specific
descendents.

I propose that we adopt the parent/child and ancestor/descendant
nomenclatures for OpenGOOP Inheritance.

Any thoughts?

-Jim



-------------------------------------------------------
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

---------------------------------
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search

[opengoop] Inheritance Nomenclature

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

Hello all,

For describing inheritance, OOP has many nomenclatures.  For example:

parent class - superclass (smalltalk), base class (C++), and ancestor =
class

child class - subclass (smalltalk), derived class (C++), and descendant
class

For OpenGOOP Inheritance, I think that we should adopt a single
nomenclature.  We should consider the fact that G programmers often do =
not
come from a CS background (I don't :-) and so I favor the parent/child =
and
ancestor/descendent nomenclatures, rather than those of C++ and =
smalltalk.
In fact, usage of parent/child and ancestor/descendant nomenclatures are =
not
mutually exclusive, since parent, grandparent, greatgrandparent, etc. =
are
specific ancestors, and child, grandchild, and greatgrandchild are =
specific
descendents.

I propose that we adopt the parent/child and ancestor/descendant
nomenclatures for OpenGOOP Inheritance.

Any thoughts?

-Jim

[lvdata] EXAMPLE - Get Object Attributes as XML.vi

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

Hello all,

I have started working on an a VI for converting LabVIEW object =
attributes
to XML format.  It makes me think about the possibility for saving =
LabVIEW
VIs as XML ;-)  It is a derivitive of the "OpenG Flatten to XML.vi" =
shown at
the 2003-05-06 OpenG Group meeting.

The Example is located on the "EXAMPLE - Get Object Attributes as XML" =
page
at OpenG.org:
<http://www.openg.org/tiki/tiki-index.php?page=3DEXAMPLE%20-%20Get%20Obje=
ct%20
Attributes%20as%20XML>

I have categorized this page as:

Documentation > Library Documentation > Library Usage Examples > LabVIEW
Data Tools Examples

I have also created a page called "EXAMPLE - OpenG Flatten to XML.vi" =
and
added it to the same category.

Cheers,

-Jim

Re: [OpenGToolkit-Developers] [opengoop] Class Type Inheritance Refnum

[Niels H. <ni...@ha...>]

Howdy,

First, - a small introduction:
I have just joined the opengtoolkit developer forum (I've been listening 
since the very start though). So, - please accept my appologies for beeing 
too ignorant - not knowing which discussions you allready have had. I've 
worked professional with LabVIEW for several years, and have been somewhat 
active on info-lv. Within the last couple of years the scope of my work has 
changed towards software configuration management/OOA/OOD, - occasionally I 
still use LV. Privately,- I've tried different ways to implement e.g. 
inherency in LV based on GOOP, but I think that working together under 
OpenG will speed up the process significantly. So, - I think my primary 
focus will be on the OpenGOOP project.

I have special interest in finding a solution in OpenGOOP for:
- inherency
- abstraction/interface

- also templates for different design patters, as identified by the Gang of 
Four.

Second,- about Jim's mail:
Just took a brief look at it.

My first impressions is: this is slick,- but I have (for now) a quick question:

Will this allways be type safe?

What about future versions of LV? Using this (implicitly casting a cluster 
of a ref and a variant into a variant) could be too close to the way LV 
represents data in memory. To me it actually looks like a flaw in LV 
(assigning clusters of different types to each other)...

All the best
---Niels



At 14:54 08-10-2003 -0700, Jim Kring wrote:
>I have just created a new page at OpenG.org called "Class Type Inheritance
>Refnum":
>
><http://www.openg.org/tiki/tiki-index.php?page=Class+Type+Inheritance+Refnum>
>
>The Class Type Inheritance Refnum (invented/discovered by Jean-Pierre
>Drolet) is a LabVIEW Data Structure scheme which behaves just like VI Server
>object (GObj) refnums. It uses variant coercion within the structure to
>allow a more child class's more-specific structural component to coerce into
>it's class-type variant element.
>
>The Class Type Inheritance Refnum will be used as the refnum type for
>OpenGOOP w/ Inheritance.  Please take a look at this.
>
>Cheers,
>
>-Jim
>
>
>
>-------------------------------------------------------
>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

[opengoop] Inheritance Requirements, Options, and Feasibility

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

I have created a page at OpenG.org called "OpenG Fwk: OpenGOOP =
Inheritance
Feasibility" located at:
<http://openg.org/tiki/tiki-index.php?page=3DOpenG+Fwk%3A+OpenGOOP+Inheri=
tance
+Feasibility>

This page can be used for aggregating information on requirements, =
possible
options, and feasibililty for OpenGOOP Inheritance.

-Jim

RE: [opengoop] Class Type Inheritance Refnum

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

I have added an example to the "Class Type Inheritance Refnum" page that
shows how to get refnum type information at run-time.  The key is that =
it
recurses into the variant data (descendants) and builds an inheritance =
list
and other useful information.

"Class Type Inheritance Refnum" page:
<http://www.openg.org/tiki/tiki-index.php?page=3DClass+Type+Inheritance+R=
efnum
>

"Example - Getting refnum type information at run-time" download:
<http://www.openg.org/tiki/tiki-download_wiki_attachment.php?attId=3D14>

Cheers,

-Jim

[opengoop] Inheritance and LV Variant bugs

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

Due to numerous Variant bugs in LabVIEW versions < 7.0 and the extensive
need for variants in implimenting OpenGOOP Inheritance and Class Type
Inheritance Refnums, it was the oppinion of Jean-Pierre Drolet and I to
develop OpenGOOP Inheritance in LabVIEW 7.0.  This should not be a problem
for the project target audience because:
 
1) OpenGOOP is an application framework and most users will therefore be
implimenting OpenGOOP solutions when greating new applications, and 
2) OpenGOOP Inheritance is an advanced developer tool, and most advanced
LabVIEW developers have access to and are actively using LabVIEW 7.0.
 
If this presents a significant problem to any developers wishing to
contribute to OpenGOOP Inheritance, please let me know.
 
-Jim Kring

Re: [OpenGToolkit-Developers] [opengoop] Class Type Inheritance Refnum

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

Hi Niels,

Niels Harre wrote:

> Howdy,
> 
> First, - a small introduction:
> I have just joined the opengtoolkit developer forum (I've been listening 
> since the very start though). So, - please accept my appologies for beeing 
> too ignorant - not knowing which discussions you allready have had. I've 
> worked professional with LabVIEW for several years, and have been somewhat 
> active on info-lv. Within the last couple of years the scope of my work has 
> changed towards software configuration management/OOA/OOD, - occasionally I 
> still use LV. Privately,- I've tried different ways to implement e.g. 
> inherency in LV based on GOOP, but I think that working together under 
> OpenG will speed up the process significantly. So, - I think my primary 
> focus will be on the OpenGOOP project.
> 
> I have special interest in finding a solution in OpenGOOP for:
> - inherency
> - abstraction/interface
> 
> - also templates for different design patters, as identified by the Gang of 
> Four.

First, welcome to the list :-)

Second, in order to impliment OOP patterns in LabVIEW we need to make sure 
that we impliment inheritance correctly.  We'll know that we are doing it 
right, if our design allows us to impliment the patterns.  I think that we 
should, from the very start, make these patterns use cases upon which we can 
base our requirments.

> Second,- about Jim's mail:
> Just took a brief look at it.
> 
> My first impressions is: this is slick,- but I have (for now) a quick 
question:
> 
> Will this allways be type safe?
> 
> What about future versions of LV? Using this (implicitly casting a cluster 
> of a ref and a variant into a variant) could be too close to the way LV 
> represents data in memory. To me it actually looks like a flaw in LV 
> (assigning clusters of different types to each other)...
> 
> All the best
> ---Niels

Yes, Niels this is safe.  Coercion of cluster elements ("casting" is not the 
right word, here) is an expected behavior (feature) of LabVIEW.  Another 
thing to consider is that there isn't really any useful data (only default 
values) flowing through the variants at run-time.  Our current plan is to 
have the actual object reference be contained in the Generic Refnum's data 
(the Refnum in the outermost cluster).  However, type information will flow 
into a parent class's Refnum Input when it recieves a child object 
reference.  This might be useful for looking up and dynamically dispatching 
to the childs implimentation of a method (but a lookup of object Class Type 
might be possible from the refnum value alone).

In the next few days, I will post information and links to information 
contained within emails exchanged between me and Jean-Pierre Drolet, over the 
past 5 months.  We have discussed many issues already.

Cheers,

-Jim

> 
> 
> 
> At 14:54 08-10-2003 -0700, Jim Kring wrote:
> >I have just created a new page at OpenG.org called "Class Type Inheritance
> >Refnum":
> >
> ><http://www.openg.org/tiki/tiki-index.php?
page=Class+Type+Inheritance+Refnum>
> >
> >The Class Type Inheritance Refnum (invented/discovered by Jean-Pierre
> >Drolet) is a LabVIEW Data Structure scheme which behaves just like VI 
Server
> >object (GObj) refnums. It uses variant coercion within the structure to
> >allow a more child class's more-specific structural component to coerce 
into
> >it's class-type variant element.
> >
> >The Class Type Inheritance Refnum will be used as the refnum type for
> >OpenGOOP w/ Inheritance.  Please take a look at this.
> >
> >Cheers,
> >
> >-Jim
> >
> >
> 

Re: [OpenGToolkit-Developers] [opengoop] Class Type Inheritance Refnum

[Niels H. <ni...@ha...>]

Howdy,

First, - a small introduction:
I have just joined the opengtoolkit developer forum (I've been listening 
since the very start though). So, - please accept my appologies for beeing 
too ignorant - not knowing which discussions you allready have had. I've 
worked professional with LabVIEW for several years, and have been somewhat 
active on info-lv. Within the last couple of years the scope of my work has 
changed towards software configuration management/OOA/OOD, - occasionally I 
still use LV. Privately,- I've tried different ways to implement e.g. 
inherency in LV based on GOOP, but I think that working together under 
OpenG will speed up the process significantly. So, - I think my primary 
focus will be on the OpenGOOP project.

I have special interest in finding a solution in OpenGOOP for:
- inherency
- abstraction/interface

- also templates for different design patters, as identified by the Gang of 
Four.

Second,- about Jim's mail:
Just took a brief look at it.

My first impressions is: this is slick,- but I have (for now) a quick question:

Will this allways be type safe?

What about future versions of LV? Using this (implicitly casting a cluster 
of a ref and a variant into a variant) could be too close to the way LV 
represents data in memory. To me it actually looks like a flaw in LV 
(assigning clusters of different types to each other)...

All the best
---Niels



At 14:54 08-10-2003 -0700, Jim Kring wrote:
>I have just created a new page at OpenG.org called "Class Type Inheritance
>Refnum":
>
><http://www.openg.org/tiki/tiki-index.php?page=Class+Type+Inheritance+Refnum>
>
>The Class Type Inheritance Refnum (invented/discovered by Jean-Pierre
>Drolet) is a LabVIEW Data Structure scheme which behaves just like VI Server
>object (GObj) refnums. It uses variant coercion within the structure to
>allow a more child class's more-specific structural component to coerce into
>it's class-type variant element.
>
>The Class Type Inheritance Refnum will be used as the refnum type for
>OpenGOOP w/ Inheritance.  Please take a look at this.
>
>Cheers,
>
>-Jim
>
>
>
>-------------------------------------------------------
>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

[OpenGToolkit-Developers] [opengoop] project and developer pages created

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

I have reorganized the OpenGOOP pages on OpenG.org.  Please take a look.
 
Cheers,
 
-Jim

[OpenGToolkit-Developers] [opengoop] Class Type Inheritance Refnum

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

I have just created a new page at OpenG.org called "Class Type =
Inheritance
Refnum":

<http://www.openg.org/tiki/tiki-index.php?page=3DClass+Type+Inheritance+R=
efnum
>

The Class Type Inheritance Refnum (invented/discovered by Jean-Pierre
Drolet) is a LabVIEW Data Structure scheme which behaves just like VI =
Server
object (GObj) refnums. It uses variant coercion within the structure to
allow a more child class's more-specific structural component to coerce =
into
it's class-type variant element.

The Class Type Inheritance Refnum will be used as the refnum type for
OpenGOOP w/ Inheritance.  Please take a look at this.

Cheers,

-Jim