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