[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