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

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)

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

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

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

[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] "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] "Variant To Data" downcasts Class Type Inheritance Refnums

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

> In fact you used the technique yourself

Ah, yes :-))

-Jim

> -----Original Message-----
> From: ope...@li...
> [mailto:ope...@li...]=20
> On Behalf Of Jean-Pierre Drolet
> Sent: Monday, October 13, 2003 6:23 PM
> To: ope...@li...
> Subject: Re: [opengoop] "Variant To Data" downcasts Class=20
> Type Inheritance Refnums
>=20
>=20
> Jim,
>=20
> In fact you used the technique yourself in "EXAMPLE - Get Obj
> Info From Ref.vi" and that made me post the message about=20
> "Class Downcast to Self.vi". This VI should indeed check if=20
> the object is valid and return an error for invalid object=20
> even if the class downcast succeeds.
>=20
> Jean-Pierre
>=20
>=20
> ----- Message d'origine -----
> De : "Jim Kring" <ji...@ji...>
> =C0 : <ope...@li...>
> Envoy=E9 : 13 octobre, 2003 20:28
> Objet : [opengoop] "Variant To Data" downcasts Class Type=20
> Inheritance Refnums
>=20
>=20
> > Based on Jean-Pierre's comments about using "Variant to Data" for
> > downcasting an inheritable data structure, I realized that=20
> "Variant to
> > Data" can be used for downcasting Class Type Inheritance Refnums
> > (analagous to "To More Specific Class" fuction).  It will=20
> 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 =3D=3D> DeLorian is OK, but Truck =3D=3D>
> 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=20
> specific type.
> > However, this check will have to be done in any downstream VI that
> > operates on the more specific type.
> >
> > -Jim
> >
> >
>=20
>=20
>=20

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

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

RE: [opengoop] Virtual Methods (Abstraction)

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

Jean-Pierre,

Actually what I am talking about is the inverse.  I am not too concerned
with an ancestor having access to descendant data, but rather I am =
concerned
with a descendant having access to ancestor's private data.  Right now =
there
is no distinction between private data and public data -- all object =
data is
public.  Therefore, a class cannot protect itself from a descendant that
doesn't fully understand its implementation (and descendants shouldn't =
have
to understand).  Maybe there could be two types of data storage, public =
and
private.  Public data would be accessible to the descendants, via their
object data clusters, and private data would not be accessible to
descendants.  Private data will not need an inheritance scheme since it =
is
only available to one class-level.

-Jim



> -----Original Message-----
> From: ope...@li...=20
> [mailto:ope...@li...]=20
> On Behalf Of Jean-Pierre Drolet
> Sent: Monday, October 13, 2003 5:40 PM
> To: ope...@li...
> Subject: Re: [opengoop] Virtual Methods (Abstraction)
>=20
>=20
> Good point, Jim
>=20
> The variant is used as a placeholder for descendant data but=20
> still makes this data available for ancestors. Not only the=20
> data but also the data name and data type. That's indeed a=20
> big violation of encapsulation ( but great for a generic=20
> Read/Write Object to INI...).
>=20
> If we can't trust developpers not touching the variant child=20
> data ( it might be easy to rebundle data with empty or bad=20
> variant), then a solution could be that "Get Object Data.vi"=20
> get the class name from the incoming refnum and returns only=20
> the data relevant for this class (e.g. empty variant). That=20
> however adds complexity because the simple "Variant to Data"=20
> conversion has to be replaced with class analysis and variant=20
> data manipulation to access data. "Set Object Data.vi" would=20
> also replace only the data known by the calling class.
>=20
> My opinion is that added complexity would cancel the benefits=20
> of automatic upcasting by coercion and downcasting by=20
> "Variant to Data"
>=20
> Jean-Pierre
>=20
>=20
> ----- 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)
>=20
>=20
> > Jean-Pierre,
> >
> > Should an OpenGOOP user who is developing a class, be given=20
> access to=20
> > the class's ancestors' data, at the bundle/unbundle node? =20
> Some people=20
> > would consider this to be a violation of encapsulation,=20
> since the user=20
> > can change ancestor data without going through the public interface=20
> > defined by the ancestor.  This could potentially allow a=20
> descentan to=20
> > break a parent's run- time characteristics. If all data in=20
> the class=20
> > hierarchy is not aggregated, then the issue of a class=20
> hierarchy data=20
> > structure is not important.
> >
> > -Jim
> >
> >
>=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)

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

Ahh...

I was sure you were talling about the "new" fact that an ancestor does ha=
ve access to child data thru the introduced variant...

The encapsulation issue also exists for embedded clusters datatypes. It m=
ay be possible for Class Get Data.vi to cast, unbundle and
return only the class specific data. More easily with inheritance cluster=
s since class specific data is bundled in a cluster. The
problem I see actually is that the parent class isn't always aware when i=
ts data is accessed so it may be important that either a)
the clild can't access parent data at all or b) it is allowed to modify i=
t but all the ancestors Get/Set Data methods are invoked to
notify that the data is accessed and modified. Maybe two methods can be u=
sed: Get/Set Class Data to access class specific data only
and Get/Set Object Data to access all object data. In the latter, Get/Set=
 methods are invoked for all classes to access data.

It is also important for the object to have private data (not get/set out=
side the class) like internal state variables. These
shouldn't be affected by get/set data operation on public variables. This=
 private data need to be store in the object data space
too.



Jean-Pierre


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


Jean-Pierre,

Actually what I am talking about is the inverse.  I am not too concerned
with an ancestor having access to descendant data, but rather I am concer=
ned
with a descendant having access to ancestor's private data.  Right now th=
ere
is no distinction between private data and public data -- all object data=
 is
public.  Therefore, a class cannot protect itself from a descendant that
doesn't fully understand its implementation (and descendants shouldn't ha=
ve
to understand).  Maybe there could be two types of data storage, public a=
nd
private.  Public data would be accessible to the descendants, via their
object data clusters, and private data would not be accessible to
descendants.  Private data will not need an inheritance scheme since it i=
s
only available to one class-level.

-Jim

RE: [opengoop] Virtual Methods (Abstraction)

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

-=3D Re: encapsulation =3D-

After doing some reading, I realize that the object data is considered =
to be
"protected" if descendants can access it, but end users cannot.  End =
user's
only have access to the object vi (public) methods.  So, I guess it is =
OK
for descendants to access ancestor data.


-=3D Re: inheritable data structure =3D-

One problem that I have with the inheritable data structure is that =
since it
is "inside-out", descendants have to "dig" into the object data cluster =
in
order to get to the descendent data -- the more levels in the =
inheritance
hierarchy, the deeper they have to go.  This seems backwards, and =
confusing
to me.  I prefer digging into the object data cluster in order to get to
ancestor data.  Plus, descendents will normally be accessing the =
descendant
data, and not normally the ancestor data, so descendent data should be
easier to get to.

The only (but very useful) advantage of the inheritable data structure =
is
that a descendant data type will coerce to an ancestor data type, and
ancestor "downcasts" to descendant using "Variant to Data".  This has =
two
implications.

1) One does not have to bundle and unbundle data in "Class Get/Set Data =
as
Parent.vi", which means that there is no manual (or "scripting") task =
that
needs to occur in order to update the bundle/unbundle nodes when a data =
type
changes.  Note that "Bundle/Unbundle by Name" breaks when an element =
name
changes, and Bundle breaks when the number of elements changes (However,
Unbundle doesn't break when the number of elements changes).

2) Data could be stored in the oldest ancestor (root), rather than the
youngest descendant.  Does this have any advantages?  One, that I can =
think
of is that there will be no dynamic calls for accessing data.  However, =
does
this amount to much and how much overhead will there be if we are =
converting
to variant and back very often, anyway?

-=3D An alternative to the inheritable data structure =3D-

The change that we made to the inheritable data structure of wrapping =
the
{class added data} in a cluster, can also be applied to the standard
inheritance cluster, for a benefit that eliminates problem #1, above
(bundle/unbundle growth).

For example let's look at a Car's data cluster:
{Car Data} =3D=3D {{LandVehicle Data},{Car Added Data}}
Where:
{LandVehicle Data} =3D {{Vehicle Data}, {LandVehicle Added Data}}

Since each object's data is a cluster of exactly two subclusters, we can
bundle and unbundle (not by name) without worrying about the nodes =
growing
in size.  Therefore {Object Added Data} can grow in size without =
changing
the number of elements in {Object Data}.

I have posted an example of this on OpenG.org called "Strict Data
Inheritance Cluster".  The page is located at:

http://www.openg.org/tiki/tiki-index.php?page=3DStrict+Data+Inheritance+C=
luste
r



-Jim




> -----Original Message-----
> From: ope...@li...=20
> [mailto:ope...@li...]=20
> On Behalf Of Jean-Pierre Drolet
> Sent: Tuesday, October 14, 2003 5:42 PM
> To: ope...@li...
> Subject: Re: [opengoop] Virtual Methods (Abstraction)
>=20
>=20
> Ahh...
>=20
> I was sure you were talling about the "new" fact that an=20
> ancestor does have access to child data thru the introduced variant...
>=20
> The encapsulation issue also exists for embedded clusters=20
> datatypes. It may be possible for Class Get Data.vi to cast,=20
> unbundle and return only the class specific data. More easily=20
> with inheritance clusters since class specific data is=20
> bundled in a cluster. The problem I see actually is that the=20
> parent class isn't always aware when its data is accessed so=20
> it may be important that either a) the clild can't access=20
> parent data at all or b) it is allowed to modify it but all=20
> the ancestors Get/Set Data methods are invoked to notify that=20
> the data is accessed and modified. Maybe two methods can be=20
> used: Get/Set Class Data to access class specific data only=20
> and Get/Set Object Data to access all object data. In the=20
> latter, Get/Set methods are invoked for all classes to access data.
>=20
> It is also important for the object to have private data (not=20
> get/set outside the class) like internal state variables.=20
> These shouldn't be affected by get/set data operation on=20
> public variables. This private data need to be store in the=20
> object data space too.
>=20
>=20
>=20
> Jean-Pierre
>=20
>=20
> ----- Message d'origine -----=20
> De : "Jim Kring" <ji...@ji...>
> =C0 : <ope...@li...>
> Envoy=E9 : 13 octobre, 2003 22:23
> Objet : RE: [opengoop] Virtual Methods (Abstraction)
>=20
>=20
> Jean-Pierre,
>=20
> Actually what I am talking about is the inverse.  I am not=20
> too concerned with an ancestor having access to descendant=20
> data, but rather I am concerned with a descendant having=20
> access to ancestor's private data.  Right now there is no=20
> distinction between private data and public data -- all=20
> object data is public.  Therefore, a class cannot protect=20
> itself from a descendant that doesn't fully understand its=20
> implementation (and descendants shouldn't have to=20
> understand).  Maybe there could be two types of data storage,=20
> public and private.  Public data would be accessible to the=20
> descendants, via their object data clusters, and private data=20
> would not be accessible to descendants.  Private data will=20
> not need an inheritance scheme since it is only available to=20
> one class-level.
>=20
> -Jim
>=20
>=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)

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

Hi Jim et al,

I have a few comments:

This "protected" data type is as indicated by it's name not as conservative 
as data carrying the term private! In LV - if a given child class can 
access it's parents "protected" data - it will/can be done,- also by end 
users. The architecture of LV is in this sense too open....  so it cannot 
be avoided. Consequently - I suggest that if we want to implement different 
data types (private, protected, public)(and we do not know which (yet)) 
then select an open data model, which isn't coupled too hard to the 
implementation.

That's the main reason - I think - we should look more in the direction of 
your latter suggestion: the alternative to the inheritable data structure.

The data structures could be arranged like this (very much as you suggest):

parent class = {{public parent data}, ... <whatever data types> ... 
,{private parent data}}

{ancestor0 public data} = {public parent data}
child0 class = {{public child0 data}, ... <whatever data types> 
...,{private child0 data}, {ancestor0 public data}}

{ancestor1 public data} = {{public child0 data}, {ancestor0 public data}}
child1 class = {{public child1 data}, ... <whatever data types> 
...,{private child1 data}, {ancestor1 public data}}

Still the bundle and unbundle (not by name) can be used.

Further - this might be a step too  far - it's the implementation of the 
class which should instantiate memory space for any objects created. This 
implies that the constructor of a child classes should call it's inherited 
constructor, which again calls his inherited constructor.
....


What´do you think?

All the best,
---Niels


At 18:46 15-10-2003 -0700, you wrote:
>-= Re: encapsulation =-
>
>After doing some reading, I realize that the object data is considered to be
>"protected" if descendants can access it, but end users cannot.  End user's
>only have access to the object vi (public) methods.  So, I guess it is OK
>for descendants to access ancestor data.
>
>
>-= Re: inheritable data structure =-
>
>One problem that I have with the inheritable data structure is that since it
>is "inside-out", descendants have to "dig" into the object data cluster in
>order to get to the descendent data -- the more levels in the inheritance
>hierarchy, the deeper they have to go.  This seems backwards, and confusing
>to me.  I prefer digging into the object data cluster in order to get to
>ancestor data.  Plus, descendents will normally be accessing the descendant
>data, and not normally the ancestor data, so descendent data should be
>easier to get to.
>
>The only (but very useful) advantage of the inheritable data structure is
>that a descendant data type will coerce to an ancestor data type, and
>ancestor "downcasts" to descendant using "Variant to Data".  This has two
>implications.
>
>1) One does not have to bundle and unbundle data in "Class Get/Set Data as
>Parent.vi", which means that there is no manual (or "scripting") task that
>needs to occur in order to update the bundle/unbundle nodes when a data type
>changes.  Note that "Bundle/Unbundle by Name" breaks when an element name
>changes, and Bundle breaks when the number of elements changes (However,
>Unbundle doesn't break when the number of elements changes).
>
>2) Data could be stored in the oldest ancestor (root), rather than the
>youngest descendant.  Does this have any advantages?  One, that I can think
>of is that there will be no dynamic calls for accessing data.  However, does
>this amount to much and how much overhead will there be if we are converting
>to variant and back very often, anyway?
>
>-= An alternative to the inheritable data structure =-
>
>The change that we made to the inheritable data structure of wrapping the
>{class added data} in a cluster, can also be applied to the standard
>inheritance cluster, for a benefit that eliminates problem #1, above
>(bundle/unbundle growth).
>
>For example let's look at a Car's data cluster:
>{Car Data} == {{LandVehicle Data},{Car Added Data}}
>Where:
>{LandVehicle Data} = {{Vehicle Data}, {LandVehicle Added Data}}
>
>Since each object's data is a cluster of exactly two subclusters, we can
>bundle and unbundle (not by name) without worrying about the nodes growing
>in size.  Therefore {Object Added Data} can grow in size without changing
>the number of elements in {Object Data}.
>
>I have posted an example of this on OpenG.org called "Strict Data
>Inheritance Cluster".  The page is located at:
>
>http://www.openg.org/tiki/tiki-index.php?page=Strict+Data+Inheritance+Cluste
>r
>
>
>
>-Jim
>
>
>
>
> > -----Original Message-----
> > From: ope...@li...
> > [mailto:ope...@li...]
> > On Behalf Of Jean-Pierre Drolet
> > Sent: Tuesday, October 14, 2003 5:42 PM
> > To: ope...@li...
> > Subject: Re: [opengoop] Virtual Methods (Abstraction)
> >
> >
> > Ahh...
> >
> > I was sure you were talling about the "new" fact that an
> > ancestor does have access to child data thru the introduced variant...
> >
> > The encapsulation issue also exists for embedded clusters
> > datatypes. It may be possible for Class Get Data.vi to cast,
> > unbundle and return only the class specific data. More easily
> > with inheritance clusters since class specific data is
> > bundled in a cluster. The problem I see actually is that the
> > parent class isn't always aware when its data is accessed so
> > it may be important that either a) the clild can't access
> > parent data at all or b) it is allowed to modify it but all
> > the ancestors Get/Set Data methods are invoked to notify that
> > the data is accessed and modified. Maybe two methods can be
> > used: Get/Set Class Data to access class specific data only
> > and Get/Set Object Data to access all object data. In the
> > latter, Get/Set methods are invoked for all classes to access data.
> >
> > It is also important for the object to have private data (not
> > get/set outside the class) like internal state variables.
> > These shouldn't be affected by get/set data operation on
> > public variables. This private data need to be store in the
> > object data space too.
> >
> >
> >
> > Jean-Pierre
> >
> >
> > ----- Message d'origine -----
> > De : "Jim Kring" <ji...@ji...>
> > À : <ope...@li...>
> > Envoyé : 13 octobre, 2003 22:23
> > Objet : RE: [opengoop] Virtual Methods (Abstraction)
> >
> >
> > Jean-Pierre,
> >
> > Actually what I am talking about is the inverse.  I am not
> > too concerned with an ancestor having access to descendant
> > data, but rather I am concerned with a descendant having
> > access to ancestor's private data.  Right now there is no
> > distinction between private data and public data -- all
> > object data is public.  Therefore, a class cannot protect
> > itself from a descendant that doesn't fully understand its
> > implementation (and descendants shouldn't have to
> > understand).  Maybe there could be two types of data storage,
> > public and private.  Public data would be accessible to the
> > descendants, via their object data clusters, and private data
> > would not be accessible to descendants.  Private data will
> > not need an inheritance scheme since it is only available to
> > one class-level.
> >
> > -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
> >
>
>
>
>-------------------------------------------------------
>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)

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

Niels,

I like your idea.  I have tried to use it as the basis for my example,
below.  In this example, each class stores its own protected and private
data; the strict inheritance structure is made accessible to =
descendants;
and only protected data (not private) are accessible to descendants.

How about using the following distinction?
 - Private: Only members of the class can access this data.
 - Protected: Only members of the class and its descendants can access =
this
data.

Below is a scheme that I think will work.  I have also posted images, =
and a
downloadable example to a new page at OpenG.org called "Strict Data
Inheritance Cluster With Private Attributes".  The page is located here:
http://www.openg.org/tiki/tiki-index.php?page=3DStrict+Data+Inheritance+C=
luste
r+With+Private+Attributes

--- Class Data Structures ---

Each class has five clusters which are typedefs:
 - {Class Protected Data} =3D Class's protected data elements
 - {Class Private Data} =3D Class's private data elements
 - {Class Data Store} =3D  {{Class Protected Data}, {Class Private =
Data}}
 - {Class Inheritance Data} =3D {{Parent Inheritance Data}, {Class =
Protected
Data}}
 - {Class Data} =3D {{Class Inheritance Data}, {Class Private Data}}

--- Class Data Access VIs ---

Class Low-Level Data Access Utility VIs: - Gets/Sets {Class Data Store}.
Only callable from Class.
 - Class Get Data Store.vi
 - Class Get Data Store to Modify.vi
 - Class Set Data Store.vi

Data Access VIs for Class to Call: - Gets/Sets {Class Data}.  Only =
callable
from Class.
 - Class Get Data.vi
 - Car Get Data to Modify.vi
 - Class Set Modified Data.vi

Data Access VIs for Child to Call: - Gets/Sets  {Class Inheritance =
Data}.
Only callable from Class's child.
 - Class Get Inheritance Data.vi
 - Class Get Inheritance Data to Modify.vi
 - Class Set Inheritance Data.vi

Let me know what you think.

-Jim


> -----Original Message-----
> From: ope...@li...=20
> [mailto:ope...@li...]=20
> On Behalf Of Niels Harre
> Sent: Thursday, October 16, 2003 5:08 PM
> To: ope...@li...
> Subject: RE: [opengoop] Virtual Methods (Abstraction)
>=20
>=20
> Hi Jim et al,
>=20
> I have a few comments:
>=20
> This "protected" data type is as indicated by it's name not=20
> as conservative=20
> as data carrying the term private! In LV - if a given child class can=20
> access it's parents "protected" data - it will/can be done,-=20
> also by end=20
> users. The architecture of LV is in this sense too open.... =20
> so it cannot=20
> be avoided. Consequently - I suggest that if we want to=20
> implement different=20
> data types (private, protected, public)(and we do not know=20
> which (yet))=20
> then select an open data model, which isn't coupled too hard to the=20
> implementation.
>=20
> That's the main reason - I think - we should look more in the=20
> direction of=20
> your latter suggestion: the alternative to the inheritable=20
> data structure.
>=20
> The data structures could be arranged like this (very much as=20
> you suggest):
>=20
> parent class =3D {{public parent data}, ... <whatever data types> ...=20
> ,{private parent data}}
>=20
> {ancestor0 public data} =3D {public parent data}
> child0 class =3D {{public child0 data}, ... <whatever data types>=20
> ...,{private child0 data}, {ancestor0 public data}}
>=20
> {ancestor1 public data} =3D {{public child0 data}, {ancestor0=20
> public data}} child1 class =3D {{public child1 data}, ...=20
> <whatever data types>=20
> ...,{private child1 data}, {ancestor1 public data}}
>=20
> Still the bundle and unbundle (not by name) can be used.
>=20
> Further - this might be a step too  far - it's the=20
> implementation of the=20
> class which should instantiate memory space for any objects=20
> created. This=20
> implies that the constructor of a child classes should call=20
> it's inherited=20
> constructor, which again calls his inherited constructor.
> ....
>=20
>=20
> What=B4do you think?
>=20
> All the best,
> ---Niels
>=20
>=20
> At 18:46 15-10-2003 -0700, you wrote:
> >-=3D Re: encapsulation =3D-
> >
> >After doing some reading, I realize that the object data is=20
> considered=20
> >to be "protected" if descendants can access it, but end=20
> users cannot. =20
> >End user's only have access to the object vi (public)=20
> methods.  So, I=20
> >guess it is OK for descendants to access ancestor data.
> >
> >
> >-=3D Re: inheritable data structure =3D-
> >
> >One problem that I have with the inheritable data structure is that=20
> >since it is "inside-out", descendants have to "dig" into the object=20
> >data cluster in order to get to the descendent data -- the=20
> more levels=20
> >in the inheritance hierarchy, the deeper they have to go. =20
> This seems=20
> >backwards, and confusing to me.  I prefer digging into the=20
> object data=20
> >cluster in order to get to ancestor data.  Plus, descendents will=20
> >normally be accessing the descendant data, and not normally the=20
> >ancestor data, so descendent data should be easier to get to.
> >
> >The only (but very useful) advantage of the inheritable data=20
> structure=20
> >is that a descendant data type will coerce to an ancestor data type,=20
> >and ancestor "downcasts" to descendant using "Variant to=20
> Data".  This=20
> >has two implications.
> >
> >1) One does not have to bundle and unbundle data in "Class=20
> Get/Set Data=20
> >as Parent.vi", which means that there is no manual (or "scripting")=20
> >task that needs to occur in order to update the=20
> bundle/unbundle nodes=20
> >when a data type changes.  Note that "Bundle/Unbundle by=20
> Name" breaks=20
> >when an element name changes, and Bundle breaks when the number of=20
> >elements changes (However, Unbundle doesn't break when the number of=20
> >elements changes).
> >
> >2) Data could be stored in the oldest ancestor (root),=20
> rather than the=20
> >youngest descendant.  Does this have any advantages?  One,=20
> that I can=20
> >think of is that there will be no dynamic calls for accessing data. =20
> >However, does this amount to much and how much overhead will=20
> there be=20
> >if we are converting to variant and back very often, anyway?
> >
> >-=3D An alternative to the inheritable data structure =3D-
> >
> >The change that we made to the inheritable data structure of=20
> wrapping=20
> >the {class added data} in a cluster, can also be applied to the=20
> >standard inheritance cluster, for a benefit that eliminates=20
> problem #1,=20
> >above (bundle/unbundle growth).
> >
> >For example let's look at a Car's data cluster:
> >{Car Data} =3D=3D {{LandVehicle Data},{Car Added Data}}
> >Where:
> >{LandVehicle Data} =3D {{Vehicle Data}, {LandVehicle Added Data}}
> >
> >Since each object's data is a cluster of exactly two subclusters, we=20
> >can bundle and unbundle (not by name) without worrying about=20
> the nodes=20
> >growing in size.  Therefore {Object Added Data} can grow in size=20
> >without changing the number of elements in {Object Data}.
> >
> >I have posted an example of this on OpenG.org called "Strict Data=20
> >Inheritance Cluster".  The page is located at:
> >
> >http://www.openg.org/tiki/tiki-index.php?page=3DStrict+Data+Inh
> eritance+C
> >luste
> >r
> >
> >
> >
> >-Jim
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: ope...@li...
> > > [mailto:ope...@li...]
> > > On Behalf Of Jean-Pierre Drolet
> > > Sent: Tuesday, October 14, 2003 5:42 PM
> > > To: ope...@li...
> > > Subject: Re: [opengoop] Virtual Methods (Abstraction)
> > >
> > >
> > > Ahh...
> > >
> > > I was sure you were talling about the "new" fact that an ancestor=20
> > > does have access to child data thru the introduced variant...
> > >
> > > The encapsulation issue also exists for embedded clusters=20
> datatypes.=20
> > > It may be possible for Class Get Data.vi to cast, unbundle and=20
> > > return only the class specific data. More easily with inheritance=20
> > > clusters since class specific data is bundled in a cluster. The=20
> > > problem I see actually is that the parent class isn't=20
> always aware=20
> > > when its data is accessed so it may be important that=20
> either a) the=20
> > > clild can't access parent data at all or b) it is allowed=20
> to modify=20
> > > it but all the ancestors Get/Set Data methods are invoked=20
> to notify=20
> > > that the data is accessed and modified. Maybe two methods can be
> > > used: Get/Set Class Data to access class specific data only
> > > and Get/Set Object Data to access all object data. In the
> > > latter, Get/Set methods are invoked for all classes to=20
> access data.
> > >
> > > It is also important for the object to have private data (not=20
> > > get/set outside the class) like internal state variables. These=20
> > > shouldn't be affected by get/set data operation on public=20
> variables.=20
> > > This private data need to be store in the object data space too.
> > >
> > >
> > >
> > > Jean-Pierre
> > >
> > >
> > > ----- Message d'origine -----
> > > De : "Jim Kring" <ji...@ji...>
> > > =C0 : <ope...@li...>
> > > Envoy=E9 : 13 octobre, 2003 22:23
> > > Objet : RE: [opengoop] Virtual Methods (Abstraction)
> > >
> > >
> > > Jean-Pierre,
> > >
> > > Actually what I am talking about is the inverse.  I am not too=20
> > > concerned with an ancestor having access to descendant data, but=20
> > > rather I am concerned with a descendant having access to=20
> ancestor's=20
> > > private data.  Right now there is no distinction between private=20
> > > data and public data -- all object data is public.  Therefore, a=20
> > > class cannot protect itself from a descendant that doesn't fully=20
> > > understand its implementation (and descendants shouldn't have to
> > > understand).  Maybe there could be two types of data storage,
> > > public and private.  Public data would be accessible to the
> > > descendants, via their object data clusters, and private data
> > > would not be accessible to descendants.  Private data will
> > > not need an inheritance scheme since it is only available to
> > > one class-level.
> > >
> > > -Jim
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: SF.net Giveback Program.=20
> > > SourceForge.net hosts over 70,000 Open Source Projects. See the=20
> > > people who have HELPED US provide better services: Click
> > > here: http://sourceforge.net/supporters.php
> > > _______________________________________________
> > > OpenGToolkit-Developers mailing list=20
> > > Ope...@li...
> > >=20
> https://lists.sourceforge.net/lists/listinfo/opengtoolkit-deve
lopers
> >
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: SF.net Giveback Program.=20
>SourceForge.net hosts over 70,000 Open Source Projects. See the people=20
>who have HELPED US provide better services: Click here:=20
>http://sourceforge.net/supporters.php
>_______________________________________________
>OpenGToolkit-Developers mailing list=20
>Ope...@li...
>https://lists.sourceforge.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

[opengoop] Data Storage and access (was: Re: [opengoop] Virtual Methods (Abstraction))

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

Hi all,

Jim,


from what I understand, you'll need many data storage , one for object pr=
otected data and one per class for private data. If there
is a storage for each class level, why don't we put both protected and pr=
ivate data in the same storage and have VIs to get access
for each class? To construct the whole object data we still use control t=
emplates for the object but fill it by reading object
storage. Specifically, to access whole object data, the leaf object (as o=
pposed to root) reads the whole parent data (for its class
level) and bundle its own protected data.

I see an advantage here as when the whole object data is accessed, code i=
s executed at each class level so the class is warned that
data is read or modified. Otherwise, when datastorage is created by the l=
eaf (root), methods to access the data are simple
read/write without the parents (childs being notified by the change. That=
's very important for encapsulation since it the current
implementation, the child can access and modify parent data.

In some other text based languages, access to data are truly methods. Whe=
n you define a property of an object, you also defines two
methods to read and write the property. It is not simply an assignment to=
 a memory space of the property. The statements

object.property =3D newvalue
value =3D object.property

are really executed as methods
object.set_property(newvalue)
value =3D object.get_property()

This way, data is encapsulated and only the class own methods can modify =
class data.

For OpenGOOP, the "car" object can actually modify the "speed" property o=
f the parent "vehicle" by setting a new value in the object
cluster but then the vehicle isn't notified immediatly of the value chang=
e. This could be done if the "car" invokes the "Vehicle Set
Speed.vi" method.

My point is that there is more in object data access than data storage I/=
O. If the class could store its own data and provide its
own methods to access it, then we would have encapsulation and protection=
. That doesn't trash the inheritance clusters we've
designed, just that these datatypes are to be bundled by accessing many l=
evels of data.

Jean-Pierre


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


Niels,

I like your idea.  I have tried to use it as the basis for my example,
below.  In this example, each class stores its own protected and private
data; the strict inheritance structure is made accessible to descendants;
and only protected data (not private) are accessible to descendants.

How about using the following distinction?
 - Private: Only members of the class can access this data.
 - Protected: Only members of the class and its descendants can access th=
is
data.

Below is a scheme that I think will work.  I have also posted images, and=
 a
downloadable example to a new page at OpenG.org called "Strict Data
Inheritance Cluster With Private Attributes".  The page is located here:
http://www.openg.org/tiki/tiki-index.php?page=3DStrict+Data+Inheritance+C=
luste
r+With+Private+Attributes

--- Class Data Structures ---

Each class has five clusters which are typedefs:
 - {Class Protected Data} =3D Class's protected data elements
 - {Class Private Data} =3D Class's private data elements
 - {Class Data Store} =3D  {{Class Protected Data}, {Class Private Data}}
 - {Class Inheritance Data} =3D {{Parent Inheritance Data}, {Class Protec=
ted
Data}}
 - {Class Data} =3D {{Class Inheritance Data}, {Class Private Data}}

--- Class Data Access VIs ---

Class Low-Level Data Access Utility VIs: - Gets/Sets {Class Data Store}.
Only callable from Class.
 - Class Get Data Store.vi
 - Class Get Data Store to Modify.vi
 - Class Set Data Store.vi

Data Access VIs for Class to Call: - Gets/Sets {Class Data}.  Only callab=
le
from Class.
 - Class Get Data.vi
 - Car Get Data to Modify.vi
 - Class Set Modified Data.vi

Data Access VIs for Child to Call: - Gets/Sets  {Class Inheritance Data}.
Only callable from Class's child.
 - Class Get Inheritance Data.vi
 - Class Get Inheritance Data to Modify.vi
 - Class Set Inheritance Data.vi

Let me know what you think.

-Jim


> -----Original Message-----
> From: ope...@li...
> [mailto:ope...@li...]
> On Behalf Of Niels Harre
> Sent: Thursday, October 16, 2003 5:08 PM
> To: ope...@li...
> Subject: RE: [opengoop] Virtual Methods (Abstraction)
>
>
> Hi Jim et al,
>
> I have a few comments:
>
> This "protected" data type is as indicated by it's name not
> as conservative
> as data carrying the term private! In LV - if a given child class can
> access it's parents "protected" data - it will/can be done,-
> also by end
> users. The architecture of LV is in this sense too open....
> so it cannot
> be avoided. Consequently - I suggest that if we want to
> implement different
> data types (private, protected, public)(and we do not know
> which (yet))
> then select an open data model, which isn't coupled too hard to the
> implementation.
>
> That's the main reason - I think - we should look more in the
> direction of
> your latter suggestion: the alternative to the inheritable
> data structure.
>
> The data structures could be arranged like this (very much as
> you suggest):
>
> parent class =3D {{public parent data}, ... <whatever data types> ...
> ,{private parent data}}
>
> {ancestor0 public data} =3D {public parent data}
> child0 class =3D {{public child0 data}, ... <whatever data types>
> ...,{private child0 data}, {ancestor0 public data}}
>
> {ancestor1 public data} =3D {{public child0 data}, {ancestor0
> public data}} child1 class =3D {{public child1 data}, ...
> <whatever data types>
> ...,{private child1 data}, {ancestor1 public data}}
>
> Still the bundle and unbundle (not by name) can be used.
>
> Further - this might be a step too  far - it's the
> implementation of the
> class which should instantiate memory space for any objects
> created. This
> implies that the constructor of a child classes should call
> it's inherited
> constructor, which again calls his inherited constructor.
> ....
>
>
> What=B4do you think?
>
> All the best,
> ---Niels
>
>
> At 18:46 15-10-2003 -0700, you wrote:
> >-=3D Re: encapsulation =3D-
> >
> >After doing some reading, I realize that the object data is
> considered
> >to be "protected" if descendants can access it, but end
> users cannot.
> >End user's only have access to the object vi (public)
> methods.  So, I
> >guess it is OK for descendants to access ancestor data.
> >
> >
> >-=3D Re: inheritable data structure =3D-
> >
> >One problem that I have with the inheritable data structure is that
> >since it is "inside-out", descendants have to "dig" into the object
> >data cluster in order to get to the descendent data -- the
> more levels
> >in the inheritance hierarchy, the deeper they have to go.
> This seems
> >backwards, and confusing to me.  I prefer digging into the
> object data
> >cluster in order to get to ancestor data.  Plus, descendents will
> >normally be accessing the descendant data, and not normally the
> >ancestor data, so descendent data should be easier to get to.
> >
> >The only (but very useful) advantage of the inheritable data
> structure
> >is that a descendant data type will coerce to an ancestor data type,
> >and ancestor "downcasts" to descendant using "Variant to
> Data".  This
> >has two implications.
> >
> >1) One does not have to bundle and unbundle data in "Class
> Get/Set Data
> >as Parent.vi", which means that there is no manual (or "scripting")
> >task that needs to occur in order to update the
> bundle/unbundle nodes
> >when a data type changes.  Note that "Bundle/Unbundle by
> Name" breaks
> >when an element name changes, and Bundle breaks when the number of
> >elements changes (However, Unbundle doesn't break when the number of
> >elements changes).
> >
> >2) Data could be stored in the oldest ancestor (root),
> rather than the
> >youngest descendant.  Does this have any advantages?  One,
> that I can
> >think of is that there will be no dynamic calls for accessing data.
> >However, does this amount to much and how much overhead will
> there be
> >if we are converting to variant and back very often, anyway?
> >
> >-=3D An alternative to the inheritable data structure =3D-
> >
> >The change that we made to the inheritable data structure of
> wrapping
> >the {class added data} in a cluster, can also be applied to the
> >standard inheritance cluster, for a benefit that eliminates
> problem #1,
> >above (bundle/unbundle growth).
> >
> >For example let's look at a Car's data cluster:
> >{Car Data} =3D=3D {{LandVehicle Data},{Car Added Data}}
> >Where:
> >{LandVehicle Data} =3D {{Vehicle Data}, {LandVehicle Added Data}}
> >
> >Since each object's data is a cluster of exactly two subclusters, we
> >can bundle and unbundle (not by name) without worrying about
> the nodes
> >growing in size.  Therefore {Object Added Data} can grow in size
> >without changing the number of elements in {Object Data}.
> >
> >I have posted an example of this on OpenG.org called "Strict Data
> >Inheritance Cluster".  The page is located at:
> >
> >http://www.openg.org/tiki/tiki-index.php?page=3DStrict+Data+Inh
> eritance+C
> >luste
> >r
> >
> >
> >
> >-Jim
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: ope...@li...
> > > [mailto:ope...@li...]
> > > On Behalf Of Jean-Pierre Drolet
> > > Sent: Tuesday, October 14, 2003 5:42 PM
> > > To: ope...@li...
> > > Subject: Re: [opengoop] Virtual Methods (Abstraction)
> > >
> > >
> > > Ahh...
> > >
> > > I was sure you were talling about the "new" fact that an ancestor
> > > does have access to child data thru the introduced variant...
> > >
> > > The encapsulation issue also exists for embedded clusters
> datatypes.
> > > It may be possible for Class Get Data.vi to cast, unbundle and
> > > return only the class specific data. More easily with inheritance
> > > clusters since class specific data is bundled in a cluster. The
> > > problem I see actually is that the parent class isn't
> always aware
> > > when its data is accessed so it may be important that
> either a) the
> > > clild can't access parent data at all or b) it is allowed
> to modify
> > > it but all the ancestors Get/Set Data methods are invoked
> to notify
> > > that the data is accessed and modified. Maybe two methods can be
> > > used: Get/Set Class Data to access class specific data only
> > > and Get/Set Object Data to access all object data. In the
> > > latter, Get/Set methods are invoked for all classes to
> access data.
> > >
> > > It is also important for the object to have private data (not
> > > get/set outside the class) like internal state variables. These
> > > shouldn't be affected by get/set data operation on public
> variables.
> > > This private data need to be store in the object data space too.
> > >
> > >
> > >
> > > Jean-Pierre
> > >
> > >
> > > ----- Message d'origine -----
> > > De : "Jim Kring" <ji...@ji...>
> > > =C0 : <ope...@li...>
> > > Envoy=E9 : 13 octobre, 2003 22:23
> > > Objet : RE: [opengoop] Virtual Methods (Abstraction)
> > >
> > >
> > > Jean-Pierre,
> > >
> > > Actually what I am talking about is the inverse.  I am not too
> > > concerned with an ancestor having access to descendant data, but
> > > rather I am concerned with a descendant having access to
> ancestor's
> > > private data.  Right now there is no distinction between private
> > > data and public data -- all object data is public.  Therefore, a
> > > class cannot protect itself from a descendant that doesn't fully
> > > understand its implementation (and descendants shouldn't have to
> > > understand).  Maybe there could be two types of data storage,
> > > public and private.  Public data would be accessible to the
> > > descendants, via their object data clusters, and private data
> > > would not be accessible to descendants.  Private data will
> > > not need an inheritance scheme since it is only available to
> > > one class-level.
> > >
> > > -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-deve
lopers
> >
>
>
>
>-------------------------------------------------------
>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




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



-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; & in the Server Room
http://www.enterpriselinuxforum.com
_______________________________________________
OpenGToolkit-Developers mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers

RE: [opengoop] Data Storage and access (was: Re: [opengoop] Virtual Methods (Abstraction))

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

Jean-Pierre,

Yes, all of your statements are in line with what we have been =
discussing.
I have put together an inheritance example that also implements virtual
methods.

http://www.OpenG.org/OpenGOOP/GeomTest_2003-10-28.zip

I don't have time, right at the moment, to list all of the features of =
this
example, but if you dive into it, you will find that there are many =
comments
in the code and I have tried not to make spaghetti ;-)

Niels and I have had some chats on MSN Messenger about the design, and =
he
mentioned that he was going to post some comments (related to the =
seperation
of public/protected/private data) to the list after I made the example
available for download.  Hopefully this should make for a good =
discussion.

BTW, I just realized that sister (and other distant relative) class
inheritance refnums do not upcast to their common ancestor at build =
array
nodes.  This is to be expected, but it was not obvious to me, as first.  =
You
will notice in the GeomTest example that I had to first upcast Circle_GF =
and
Rectangle_GF to GeometricFigure before I could build an array of
GeometricFigures.

-Jim


> -----Original Message-----
> From: ope...@li...=20
> [mailto:ope...@li...]=20
> On Behalf Of Jean-Pierre Drolet
> Sent: Sunday, October 26, 2003 7:45 AM
> To: ope...@li...
> Subject: [opengoop] Data Storage and access (was: Re:=20
> [opengoop] Virtual Methods (Abstraction))
>=20
>=20
> Hi all,
>=20
> Jim,
>=20
>=20
> from what I understand, you'll need many data storage , one=20
> for object protected data and one per class for private data.=20
> If there is a storage for each class level, why don't we put=20
> both protected and private data in the same storage and have=20
> VIs to get access for each class? To construct the whole=20
> object data we still use control templates for the object but=20
> fill it by reading object storage. Specifically, to access=20
> whole object data, the leaf object (as opposed to root) reads=20
> the whole parent data (for its class
> level) and bundle its own protected data.
>=20
> I see an advantage here as when the whole object data is=20
> accessed, code is executed at each class level so the class=20
> is warned that data is read or modified. Otherwise, when=20
> datastorage is created by the leaf (root), methods to access=20
> the data are simple read/write without the parents (childs=20
> being notified by the change. That's very important for=20
> encapsulation since it the current implementation, the child=20
> can access and modify parent data.
>=20
> In some other text based languages, access to data are truly=20
> methods. When you define a property of an object, you also=20
> defines two methods to read and write the property. It is not=20
> simply an assignment to a memory space of the property. The statements
>=20
> object.property =3D newvalue
> value =3D object.property
>=20
> are really executed as methods
> object.set_property(newvalue)
> value =3D object.get_property()
>=20
> This way, data is encapsulated and only the class own methods=20
> can modify class data.
>=20
> For OpenGOOP, the "car" object can actually modify the=20
> "speed" property of the parent "vehicle" by setting a new=20
> value in the object cluster but then the vehicle isn't=20
> notified immediatly of the value change. This could be done=20
> if the "car" invokes the "Vehicle Set Speed.vi" method.
>=20
> My point is that there is more in object data access than=20
> data storage I/O. If the class could store its own data and=20
> provide its own methods to access it, then we would have=20
> encapsulation and protection. That doesn't trash the=20
> inheritance clusters we've designed, just that these=20
> datatypes are to be bundled by accessing many levels of data.
>=20
> Jean-Pierre
>=20
>=20
> ----- Message d'origine -----=20
> De : "Jim Kring" <ji...@ji...>
> =C0 : <ope...@li...>
> Envoy=E9 : 17 octobre, 2003 15:04
> Objet : RE: [opengoop] Virtual Methods (Abstraction)
>=20
>=20
> Niels,
>=20
> I like your idea.  I have tried to use it as the basis for my=20
> example, below.  In this example, each class stores its own=20
> protected and private data; the strict inheritance structure=20
> is made accessible to descendants; and only protected data=20
> (not private) are accessible to descendants.
>=20
> How about using the following distinction?
>  - Private: Only members of the class can access this data.
>  - Protected: Only members of the class and its descendants=20
> can access this data.
>=20
> Below is a scheme that I think will work.  I have also posted=20
> images, and a downloadable example to a new page at OpenG.org=20
> called "Strict Data Inheritance Cluster With Private=20
> Attributes".  The page is located here:=20
> http://www.openg.org/tiki/tiki-index.php?page=3DStrict+Data+Inhe
> ritance+Cluste
> r+With+Private+Attributes
>=20
> --- Class Data Structures ---
>=20
> Each class has five clusters which are typedefs:
>  - {Class Protected Data} =3D Class's protected data elements
>  - {Class Private Data} =3D Class's private data elements
>  - {Class Data Store} =3D  {{Class Protected Data}, {Class=20
> Private Data}}
>  - {Class Inheritance Data} =3D {{Parent Inheritance Data},=20
> {Class Protected Data}}
>  - {Class Data} =3D {{Class Inheritance Data}, {Class Private Data}}
>=20
> --- Class Data Access VIs ---
>=20
> Class Low-Level Data Access Utility VIs: - Gets/Sets {Class=20
> Data Store}. Only callable from Class.
>  - Class Get Data Store.vi
>  - Class Get Data Store to Modify.vi
>  - Class Set Data Store.vi
>=20
> Data Access VIs for Class to Call: - Gets/Sets {Class Data}. =20
> Only callable from Class.
>  - Class Get Data.vi
>  - Car Get Data to Modify.vi
>  - Class Set Modified Data.vi
>=20
> Data Access VIs for Child to Call: - Gets/Sets  {Class=20
> Inheritance Data}. Only callable from Class's child.
>  - Class Get Inheritance Data.vi
>  - Class Get Inheritance Data to Modify.vi
>  - Class Set Inheritance Data.vi
>=20
> Let me know what you think.
>=20
> -Jim
>=20
>=20
> > -----Original Message-----
> > From: ope...@li...
> > [mailto:ope...@li...]
> > On Behalf Of Niels Harre
> > Sent: Thursday, October 16, 2003 5:08 PM
> > To: ope...@li...
> > Subject: RE: [opengoop] Virtual Methods (Abstraction)
> >
> >
> > Hi Jim et al,
> >
> > I have a few comments:
> >
> > This "protected" data type is as indicated by it's name not as=20
> > conservative as data carrying the term private! In LV - if a given=20
> > child class can access it's parents "protected" data - it=20
> will/can be=20
> > done,- also by end
> > users. The architecture of LV is in this sense too open....
> > so it cannot
> > be avoided. Consequently - I suggest that if we want to
> > implement different
> > data types (private, protected, public)(and we do not know
> > which (yet))
> > then select an open data model, which isn't coupled too hard to the
> > implementation.
> >
> > That's the main reason - I think - we should look more in the=20
> > direction of your latter suggestion: the alternative to the=20
> > inheritable data structure.
> >
> > The data structures could be arranged like this (very much as you=20
> > suggest):
> >
> > parent class =3D {{public parent data}, ... <whatever data types> =
...=20
> > ,{private parent data}}
> >
> > {ancestor0 public data} =3D {public parent data}
> > child0 class =3D {{public child0 data}, ... <whatever data types>=20
> > ...,{private child0 data}, {ancestor0 public data}}
> >
> > {ancestor1 public data} =3D {{public child0 data}, {ancestor0 public =

> > data}} child1 class =3D {{public child1 data}, ... <whatever=20
> data types>
> > ...,{private child1 data}, {ancestor1 public data}}
> >
> > Still the bundle and unbundle (not by name) can be used.
> >
> > Further - this might be a step too  far - it's the=20
> implementation of=20
> > the class which should instantiate memory space for any objects
> > created. This
> > implies that the constructor of a child classes should call
> > it's inherited
> > constructor, which again calls his inherited constructor.
> > ....
> >
> >
> > What=B4do you think?
> >
> > All the best,
> > ---Niels
> >
> >
> > At 18:46 15-10-2003 -0700, you wrote:
> > >-=3D Re: encapsulation =3D-
> > >
> > >After doing some reading, I realize that the object data is
> > considered
> > >to be "protected" if descendants can access it, but end
> > users cannot.
> > >End user's only have access to the object vi (public)
> > methods.  So, I
> > >guess it is OK for descendants to access ancestor data.
> > >
> > >
> > >-=3D Re: inheritable data structure =3D-
> > >
> > >One problem that I have with the inheritable data=20
> structure is that=20
> > >since it is "inside-out", descendants have to "dig" into=20
> the object=20
> > >data cluster in order to get to the descendent data -- the
> > more levels
> > >in the inheritance hierarchy, the deeper they have to go.
> > This seems
> > >backwards, and confusing to me.  I prefer digging into the
> > object data
> > >cluster in order to get to ancestor data.  Plus, descendents will=20
> > >normally be accessing the descendant data, and not normally the=20
> > >ancestor data, so descendent data should be easier to get to.
> > >
> > >The only (but very useful) advantage of the inheritable data
> > structure
> > >is that a descendant data type will coerce to an ancestor=20
> data type,=20
> > >and ancestor "downcasts" to descendant using "Variant to
> > Data".  This
> > >has two implications.
> > >
> > >1) One does not have to bundle and unbundle data in "Class
> > Get/Set Data
> > >as Parent.vi", which means that there is no manual (or=20
> "scripting")=20
> > >task that needs to occur in order to update the
> > bundle/unbundle nodes
> > >when a data type changes.  Note that "Bundle/Unbundle by
> > Name" breaks
> > >when an element name changes, and Bundle breaks when the number of=20
> > >elements changes (However, Unbundle doesn't break when the=20
> number of=20
> > >elements changes).
> > >
> > >2) Data could be stored in the oldest ancestor (root),
> > rather than the
> > >youngest descendant.  Does this have any advantages?  One,
> > that I can
> > >think of is that there will be no dynamic calls for=20
> accessing data.=20
> > >However, does this amount to much and how much overhead will
> > there be
> > >if we are converting to variant and back very often, anyway?
> > >
> > >-=3D An alternative to the inheritable data structure =3D-
> > >
> > >The change that we made to the inheritable data structure of
> > wrapping
> > >the {class added data} in a cluster, can also be applied to the=20
> > >standard inheritance cluster, for a benefit that eliminates
> > problem #1,
> > >above (bundle/unbundle growth).
> > >
> > >For example let's look at a Car's data cluster:
> > >{Car Data} =3D=3D {{LandVehicle Data},{Car Added Data}}
> > >Where:
> > >{LandVehicle Data} =3D {{Vehicle Data}, {LandVehicle Added Data}}
> > >
> > >Since each object's data is a cluster of exactly two=20
> subclusters, we=20
> > >can bundle and unbundle (not by name) without worrying about
> > the nodes
> > >growing in size.  Therefore {Object Added Data} can grow in size=20
> > >without changing the number of elements in {Object Data}.
> > >
> > >I have posted an example of this on OpenG.org called "Strict Data=20
> > >Inheritance Cluster".  The page is located at:
> > >
> > >http://www.openg.org/tiki/tiki-index.php?page=3DStrict+Data+Inh
> > eritance+C
> > >luste
> > >r
> > >
> > >
> > >
> > >-Jim
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: ope...@li...
> > > > [mailto:ope...@li...]
> > > > On Behalf Of Jean-Pierre Drolet
> > > > Sent: Tuesday, October 14, 2003 5:42 PM
> > > > To: ope...@li...
> > > > Subject: Re: [opengoop] Virtual Methods (Abstraction)
> > > >
> > > >
> > > > Ahh...
> > > >
> > > > I was sure you were talling about the "new" fact that=20
> an ancestor=20
> > > > does have access to child data thru the introduced variant...
> > > >
> > > > The encapsulation issue also exists for embedded clusters
> > datatypes.
> > > > It may be possible for Class Get Data.vi to cast, unbundle and=20
> > > > return only the class specific data. More easily with=20
> inheritance=20
> > > > clusters since class specific data is bundled in a cluster. The=20
> > > > problem I see actually is that the parent class isn't
> > always aware
> > > > when its data is accessed so it may be important that
> > either a) the
> > > > clild can't access parent data at all or b) it is allowed
> > to modify
> > > > it but all the ancestors Get/Set Data methods are invoked
> > to notify
> > > > that the data is accessed and modified. Maybe two methods can be
> > > > used: Get/Set Class Data to access class specific data only and=20
> > > > Get/Set Object Data to access all object data. In the latter,=20
> > > > Get/Set methods are invoked for all classes to
> > access data.
> > > >
> > > > It is also important for the object to have private data (not=20
> > > > get/set outside the class) like internal state variables. These=20
> > > > shouldn't be affected by get/set data operation on public
> > variables.
> > > > This private data need to be store in the object data space too.
> > > >
> > > >
> > > >
> > > > Jean-Pierre
> > > >
> > > >
> > > > ----- Message d'origine -----
> > > > De : "Jim Kring" <ji...@ji...>
> > > > =C0 : <ope...@li...>
> > > > Envoy=E9 : 13 octobre, 2003 22:23
> > > > Objet : RE: [opengoop] Virtual Methods (Abstraction)
> > > >
> > > >
> > > > Jean-Pierre,
> > > >
> > > > Actually what I am talking about is the inverse.  I am not too=20
> > > > concerned with an ancestor having access to descendant=20
> data, but=20
> > > > rather I am concerned with a descendant having access to
> > ancestor's
> > > > private data.  Right now there is no distinction=20
> between private=20
> > > > data and public data -- all object data is public. =20
> Therefore, a=20
> > > > class cannot protect itself from a descendant that=20
> doesn't fully=20
> > > > understand its implementation (and descendants=20
> shouldn't have to=20
> > > > understand).  Maybe there could be two types of data storage,=20
> > > > public and private.  Public data would be accessible to the=20
> > > > descendants, via their object data clusters, and private data=20
> > > > would not be accessible to descendants.  Private data will not=20
> > > > need an inheritance scheme since it is only available to one=20
> > > > class-level.
> > > >
> > > > -Jim
> > > >
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.net email is sponsored by: SF.net Giveback Program.=20
> > > > SourceForge.net hosts over 70,000 Open Source Projects. See the=20
> > > > people who have HELPED US provide better services: Click
> > > > here: http://sourceforge.net/supporters.php
> > > > _______________________________________________
> > > > OpenGToolkit-Developers mailing list=20
> > > > Ope...@li...
> > > >
> > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-deve
> lopers
> > >
> >
> >
> >
> >-------------------------------------------------------
> >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=20
> >who have HELPED US provide better services: Click here:=20
> >http://sourceforge.net/supporters.php
> >_______________________________________________
> >OpenGToolkit-Developers mailing list=20
> >Ope...@li...
> >https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers
>=20
>=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 sponsored by: Enterprise Linux Forum=20
> Conference & Expo The Event For Linux Datacenter Solutions &=20
> Strategies in The Enterprise Linux in the Boardroom; in the=20
> Front Office; & in the Server Room http://www.enterpriselinuxforum.com
> _______________________________________________
> 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: The SF.net Donation=20
> Program. Do you like what SourceForge.net is doing for the=20
> Open Source Community?  Make a contribution, and help us add=20
> new features and functionality. Click here:=20
> http://sourceforge.net/donate/=20
> _______________________________________________
> OpenGToolkit-Developers mailing list=20
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers
>=20