Re: [opengoop] Virtual Methods (Abstraction)

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

Jean-Pierre,

Should an OpenGOOP user who is developing a class, be given access to the 
class's ancestors' data, at the bundle/unbundle node?  Some people would 
consider this to be a violation of encapsulation, since the user can change 
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 aggregated, 
then the issue of a class hierarchy data structure is not important.

-Jim


Jean-Pierre Drolet <jea...@tr...> said:

> Yes Jim,
> 
> In the other scheme of inheritance, the datatype grows outwards e.g. the 
child datatype is constructed as embedded clusters:
> 
> child typedef: {child added data,{parent data}}
> 
> and is linked directly to immediate parent typedef
> 
> In the proposed scheme, the datatype grows inwards e.g. the inner variant 
is replaced with the cluster {{child added data},variant}
> 
> child typedef: {{parent added data},{{child1 added data},{{child added 
data},variant}}}
> 
> then it is not linked directly to immediate parent typedef but to all 
{parent added data} typedefs. We have to create two data
> typedefs for the class, {class added data} and inheritance data typedef.
> 
> I also thought of a simplified, non-embedding approach, provided that we 
limit the number of inheritance levels to say five levels:
> 
> generic object datatype: cluster of 5 variants {variant, variant, variant, 
variant, variant}
> 1st generation object: {{parent data}, variant, variant, variant, variant}
> 2nd generation object: {{parent data}, {child data}, variant, variant, 
variant}
> and so on.
> 
> Thise scheme also preserves the class casting behavior but is limited to a 
fix number of inheritance levels. Objects Refnums could
> also be flattened instead of embedded.
> 
> Jean-Pierre
> 
> 
> ----- Message d'origine ----- 
> De : "Jim Kring" <ji...@ji...>
> À : <ope...@li...>
> Envoyé : 13 octobre, 2003 12:27
> Objet : RE: [opengoop] Virtual Methods (Abstraction)
> 
> 
> Jean-Pierre,
> 
> The problem is that a child is going to replace the variant with its own
> data cluster.  If this variant is contained within the parent's data
> cluster, then the child must either edit or copy the parent's cluster.  But,
> the child is not allowed to edit the parent's cluster (we want the
> possibility of several children), so the only option is to make a copy of
> the parent's cluster.  This means that if the parent changes, we have to
> also replicate the changes in the child's cluster.  We don't want to do
> this, we want to link to the parent's data cluster.  So, we should separate
> the parent's data from the Data Type Inheritance Cluster by means of putting
> the parent's data into its own cluster.
> 
> -Jim
> 
> .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
> 



--