MF-Types and Inheritance

Stephan Diehl (diehl@cs.uni-sb.de)
Mon, 21 Apr 1997 18:37:15 +0200

Sungwoo came up with the idea to combine new
values with inherited values in MF-Types:

CLASS HatRobot [ exposedField SFFloat size 1. ]
{ Robot { children [ SUPER.children D{} ] }
}

Usually values are inherited as they are or
totally overwritten. The idea in the above case
is that two lists are concatenated: the value
of the children-field of the superclass and the
list [ D {} ].

Sungwoo argues, that this is easy to implement,
and I am sure, his way to implement would be
by having the preprocessor take the textual
representatio of the value of the children-field
in the superclass Robot and combine in an appropriate
way (there are several cases here with [ D { } ].

At this point it is important to raise another
issue, the issue of external classes. A major
motivation for object oriented extensions is
that they should provide a better interface to
libraries allowing modularity and separate
compilation. So if we inherit from an external
class, it should be impossible for the preprocessor
to access the textual representation of that
class. (this issue is related to the issue
of dynamic and static linking)

Another consequence of the textual replacement
strategy would be, that if we change
the implementation of a class (not its properties),
then we would have to run all its subclasses
through the preprocessor again.

A way to implement it, so that access to the
superclass is not needed before run-time (rendering time),
is to create a (not rendered, e.g. non-first node
in a PROTO) instance of its superclass and use the
addChildren-Events. But this works only for some
Grouping nodes with a children field. In general
we would have to use a Script to access the
array A representing the MF-value of the superclass,
then we would create a new array which contains
the elements of A and the new elements (e.g. D {}).

What do you think of this way? Is it too complicated?
I think, this will allow independent preprocessing
of files which would only be related by EXTERNCLASS
definitions.

Cheers
-- Stephan

---------------------------------------------------------------
Dr. Stephan Diehl Tel.: ++49-681/302-3915
EMAIL: diehl@cs.uni-sb.de WWW: http://www.rw.cdl.uni-saarland.de/private/diehl
---------------------------------------------------------------
There is no place like $HOME
---------------------------------------------------------------