RE: [opengoop] Virtual Methods (Abstraction)

[Jim K. <ji...@ji...>]

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



> -----Original Message-----
> From: ope...@li...=20
> [mailto:ope...@li...]=20
> On Behalf Of Jean-Pierre Drolet
> Sent: Monday, October 13, 2003 5:40 PM
> To: ope...@li...
> Subject: Re: [opengoop] Virtual Methods (Abstraction)
>=20
>=20
> Good point, Jim
>=20
> The variant is used as a placeholder for descendant data but=20
> still makes this data available for ancestors. Not only the=20
> data but also the data name and data type. That's indeed a=20
> big violation of encapsulation ( but great for a generic=20
> Read/Write Object to INI...).
>=20
> If we can't trust developpers not touching the variant child=20
> data ( it might be easy to rebundle data with empty or bad=20
> variant), then a solution could be that "Get Object Data.vi"=20
> get the class name from the incoming refnum and returns only=20
> the data relevant for this class (e.g. empty variant). That=20
> however adds complexity because the simple "Variant to Data"=20
> conversion has to be replaced with class analysis and variant=20
> data manipulation to access data. "Set Object Data.vi" would=20
> also replace only the data known by the calling class.
>=20
> My opinion is that added complexity would cancel the benefits=20
> of automatic upcasting by coercion and downcasting by=20
> "Variant to Data"
>=20
> Jean-Pierre
>=20
>=20
> ----- Message d'origine -----=20
> De : "Jim Kring" <ji...@ji...>
> =C0 : <ope...@li...>
> Envoy=E9 : 13 octobre, 2003 19:45
> Objet : Re: [opengoop] Virtual Methods (Abstraction)
>=20
>=20
> > Jean-Pierre,
> >
> > Should an OpenGOOP user who is developing a class, be given=20
> access to=20
> > the class's ancestors' data, at the bundle/unbundle node? =20
> Some people=20
> > would consider this to be a violation of encapsulation,=20
> since the user=20
> > can change ancestor data without going through the public interface=20
> > defined by the ancestor.  This could potentially allow a=20
> descentan to=20
> > break a parent's run- time characteristics. If all data in=20
> the class=20
> > hierarchy is not aggregated, then the issue of a class=20
> hierarchy data=20
> > structure is not important.
> >
> > -Jim
> >
> >
>=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