>
> 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 {} ].
1)
The idea of 'structural definition' applies not only to
MF-types, but to all field types.
I've explained this simple idea before.
For a clear discussion, let's revisit the idea.
In a former mail, I explained 'structural definition' by an
example:
CLASS Test [ field SFFloat a 1
field SFFloat b 2
field SFFloat c 3
] {
...
# field 'sample' is of type SFVec3f
sample a b c
...
}
If SFVec3f type was defined as 'SFFlaot SFFloat SFFloat',
field 'sample' is computed from three other independant fields, namely,
'a','b',and 'c'.
Other examples may include such as:
sample a b 0.0
sample Super.c 1.0 1.0
# Here, the super class has an SFFloat field 'c'.
An important point, I think, is that the value of field 'sample'
is computed not statically. That is, it is determined each time
the browser composes a frame. Hence, at runtime, if the value of field
'a' is changed, the value of field 'sample' is also changed in the first
example.
This is the basis of why I said the implementation is easy. See below.
>
> 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.
2)
Excuse me because my strategy is not the textual replacement
algorithm. ^^;
Consider the following example. In file A, classes Robot and HatRobot
are defined. In file B is defined class YellowHatRobot which is a subclass
of class HatRobot.
# class definition
# in file A
CLASS Robot [] {
Transform {
children [ A{} B{} C{} ]
}
}
CLASS HatRobot [ ] {
Robot {
children [ SUPER.children D{} ]
}
}
# in another file B
EXTERNCLASS HatRobot ....
CLASS YellowHatRobot [] {
HatRobot {
children [ SUPER.children E{} ]
}
}
DEF TestNode YellowHatRobot[]
What should be first noticed is that, in the stage of rendering,
all the definitions of 'classes' used should be available to
the browser. The 'classes' include superclasses which a class is
a subclass of. Assume that our browser reads in file B, and tries to
render TestNode. Since class YellowHatRobot refers to class HatRobot,
file A should be also read in, which means the browser can make use of
the definition of class HatRobot (and also the definition of class Robot).
If the browser couldn't access to the definitions of two super classes,
then, node TestNode couldn't be rendered, either.
Then, how does the browser render node TestNode ???
I've explained in a former mail that the browser treats node TestNode
as a Transform node in the final stage of rendering.
(If you don't understand this assertion, please, read my former mail.
The mail includes :
--------------------
In other words, when subclassing a class, we only have to define the
structure of fields of the class. For example, consider the following
example. Notice that the SELF keyword occurs only once inside the
definition of subclass.
CLASS Toy EXTENDS Transform [ ] {
SELF {
children [
A {}
B {}
C {}
]
}
}
In class Toy, it states as :
"This class is actually a Transform class. But the difference is that
the 'children' field is defined as [ A{} B{} C{} ]."
----------------------
Then, all the remaining work is to determine the values of fields
of a top class. For example, in the above example, the top class of
class YellowHatRobot is Transform class. We only have to
determine the values of fields in Transform class. (Do you agree ?)
The class hierarchy is:
Transform - Robot - HatRobot - YellowHatRobot
In YellowHatRobot, children is defined as:
children [ SUPER.children E{} ]
Then, the browser might invoke a internal pseudo function such as:
MFNode HatRobot.children()
This is a function, that is shared by all instances of class HatRobot.
It invokes in turn its superclass' function such as:
MFNode Robot.children()
In this way, I think the problem could be solved.
Of course, this approach has many faults and errors.
I will think again, and reformulate this strategy tomorrow in better form.
Thank you.
>
> 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.
I will answer your question later.
>
> 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
> ---------------------------------------------------------------
>
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Sungwoo Park, (Castle-Help Naive) homepage : http://compiler.kaist.ac.kr/~gladius e-mail : gladius@compiler.kaist.ac.kr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -