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