RE: [opengoop] Virtual Methods (Abstraction)

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

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