Re: [opengoop] Virtual Methods (Abstraction)

[Jean-Pierre D. <jea...@tr...>]

Good point, Jim

The variant is used as a placeholder for descendant data but still makes =
this data available for ancestors. Not only the data but
also the data name and data type. That's indeed a big violation of encaps=
ulation ( but great for a generic Read/Write Object to
INI...).

If we can't trust developpers not touching the variant child data ( it mi=
ght be easy to rebundle data with empty or bad variant),
then a solution could be that "Get Object Data.vi" get the class name fro=
m the incoming refnum and returns only the data relevant
for this class (e.g. empty variant). That however adds complexity because=
 the simple "Variant to Data" conversion has to be replaced
with class analysis and variant data manipulation to access data. "Set Ob=
ject Data.vi" would also replace only the data known by the
calling class.

My opinion is that added complexity would cancel the benefits of automati=
c upcasting by coercion and downcasting by "Variant to
Data"

Jean-Pierre


----- 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)


> Jean-Pierre,
>
> Should an OpenGOOP user who is developing a class, be given access to t=
he
> class's ancestors' data, at the bundle/unbundle node?  Some people woul=
d
> consider this to be a violation of encapsulation, since the user can ch=
ange
> ancestor data without going through the public interface defined by the
> ancestor.  This could potentially allow a descentan to break a parent's=
 run-
> time characteristics. If all data in the class hierarchy is not aggrega=
ted,
> then the issue of a class hierarchy data structure is not important.
>
> -Jim
>
>