Hi, OO-Extension Enthusiasts,
I will dare to try the third.
This idea is neither smart nor new. However, I will explain the
underlying basis for the idea.
1)
Consider the prototype description for Transform nodes.
Transform {
eventIn MFNode addChildren
eventIn MFNode removeChildren
exposedField SFVec3f center 0 0 0
exposedField MFNode children []
exposedField SFRotation rotation 0 0 1 0
exposedField SFVec3f scale 1 1 1
exposedField SFRotation scaleOrientation 0 0 1 0
exposedField SFVec3f translation 0 0 0
field SFVec3f bboxCenter 0 0 0
field SFVec3f bboxSize -1 -1 -1
}
There are 2 eventIns, 6 exposedFields, and 2 fields.
What we should notice is that the VRML browser employs only the
fields and exposedFields of a Transform node when it renders the node.
For the ease of discussion, let set FIELD be defined as:
FIELD = { center,children,rotation,scale,scaleOrientation,translation }
Then, the browser would employ only set FIELD when rendering the node.
Also, the functionality of Transform nodes is specified by VRML 2.0
language itself, and the broswser would implement the specification.
We can change neither this specification nor the implementation
provided by the browser.
Additionally, the associate behavior of those eventIns is predefined.
We may assume that the browser has written the asscociate code into
itself.
2)
Next, we want to create a new class which is extended from Transform.
Assume that this class is 'BarTransform' and that it has an SFVec3f
exposedField 'position' which determines the amount of 'translation'.
In VRML 2.0, we could achieve this by
PROTO BarTransform [ exposedField SFVec3f position 0 0 0 ] {
Transform {
translation IS position
}
}
Let's analyze the class BarTransform.
The fields of the BarTransform class are those in set FIELD + { position }.
When rendering the scene, the browser STILL employs only set FIELD.
Don't misapprehend the above statement. It states that the browser employs
the final values of set FIELD.
For example, if we set 'position' to 1 1 1, then 'translation' is also set
to 1 1 1 accordingly because we specified that "translation IS position".
The browser takes the value 1 1 1 from 'translation' field, not from
'position' field.
We may add extra fields or exposedFields as we define more subclasses.
However, in the final stage of rendition by the browser, used are only
the fields or exposedFields of the class of which the browser presents
its implementation.
For instance, see the next class hierarchy.
Transform - ................................ - FinalTransform
( 1000 times of subclassing !!!)
However, when processing FinalTransform nodes, STILL the browser employs
only the final values of set FIELD in its final rendition step.
Hence, we may attach additional fields or exposedFields as we subclasses
the original class. However, they should be used only to determine the
computation process of fields or exposedFields in the original class.
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{} ]."
Hence, I think, in order to define a new subclass, we only have to
redefine the structures of superclass' fields in terms of constant values
or incoming fields (parameter fields). 'Constant values' indicates
any field values explicitly defined, such as '123', 'Transform {...}'.
3)
Note that the notion of adding the superclass' instance to the children
field is very undesirable in this idea. We should treat 'children' field
equally as other nodes.
Stephan mentioned the following suggestion.
> - superclass instances are added to the
> body of the PROTO (the VRML++ way)
For this purpose, I suggest the use of both 'SUPER' keyword and 'SELF'
keyword. The meaning of 'SELF' is obvious. 'SUPER.fld' indicates the
structure of field 'fld' of its superclass.
^^^^^^^^^
For example, assume that we've defined a class 'Robot' as:
CLASS Robot EXTENDS Transform [ exposedField SFFloat height 1. ] {
SELF {
children [ A{} B{} C{} ]
}
}
Robot's fields (including exposedFields) are FIELD + { height }.
The structure of 'children' field is [ A{} B{} C{} ].
Now, we want to define new class HatRobot, which wears his hat on as:
CLASS HatRobot EXTENDS Robot [ exposedField SFFloat size 1. [ {
SELF {
children [ SUPER.children D{} ]
}
}
The structure of 'children' field is now [ [ A{} B{} C{} ] D{} ], which
is equal to [ A{} B{} C{} D{} ]. If we wrote differently, namely, as
children [ D{} ]
then, the structure would be just [ D{} ].
In summary, the value of a field given on class definition is actually
the structure of the field. Of course, the structure may contain constant
values, as A{}, B{}, C{} or D{} in the above example. We specify the
field values when instantiating the class in order to evaluate the
'structure'. Then, any class definition would be like (in regular
expression) :
CLASS NewClass EXTENDS SuperClass [
( interface declaration )*
] {
SELF {
( ( any field of SuperClass ) ( it's new structure) )*
^^^^^^^^^^
}
( ( event handler definition )* | ( Script | ROUTE ) * )
}
Note that the keyword 'IS' is never required. Also, notice 'SuperClass'.
^^^^^^^^^^
The fields in interface declaration are new fields.
As we create subclasses more and more from a single Ultra_Super_Class,
the fields included in the subclass are accumulated more and more.
However, we don't have to worry about any problems caused by this
strategy. The reason is that there is no recursive structural definition
for any fields in any subclasses, ONLY IF the following condition holds
true in any case:
The structural definition of a field of class A may not be defined
in terms of fields of A's super class's field.
Note that the structure of a field of class A can be defined only in
A's subclasses.
4)
Above is my proposal for handling inheritances, especially with respect
to fields and exposedFields. Our discussion about eventIns and eventOuts
could be proceeded only after we've arrived at conclusion on whether
we would employ event handler strategy or ROUTE strategy.
Please, think about counter examples which exhibit the flaws of my proposal.
They would be helpful for making robust our final proposal.
Thanks.
-- Sung=Castle, Woo=Help, Park=Naive
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sungwoo Park, (Castle-Help Naive)
homepage : http://compiler.kaist.ac.kr/~gladius
e-mail : gladius@compiler.kaist.ac.kr
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -