RE: [opengoop] Virtual Methods (Abstraction)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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