Re: Subtyping and Subclasses

Park SungWoo (gladius@compiler.kaist.ac.kr)
Sat, 12 Apr 1997 07:33:08 +0900 (KST)

> However, I think, we should note that extending only one class is very
> useful. For example, suppose that we've already defined a class 'Robot'.
> We want the robot to have his hat on. Then, we can do as follows:
>
> CLASS NewRobot EXTENDS Robot [ ...] {
> Transform {...} # only describes his hat.
> }
>
> Note that, in this proposal, the description of 'Robot' is added
^^^^^^
->'hat' (my mistake)
> automatically.

1)
I've found that the idea of 'adding nodes' is not clear.
For example, in the above example, can only Transform{} node be added to??
Why not for Shape{} node ??
That is, in the next example,

CLASS NewRobot EXTENDS Robot [ ...] {
Shape {...} # only describes his hat.
}

does adding Shape{}(or else) node cause errors ?

I've concluded that the idea of 'adding nodes in inheritance' is very poor.
Consider the next examples: (These are just the short sketch of my
current idea. Besides, I am sorry for assuming that single inheritance is
only supported.)

CLASS Robot [...] {
Transform {
children [
A{}
B{}
]
}
}

CLASS Robot EXTENDS Transform [...] {
DEF SELF {
children [USE A, USE B]
}
DEF A ... # not directly added
DEF B ... # not directly added
}

In the first example, Robot is a subclass of SFNode, and Transform{} node
is added to it. Then, we cannot probably state clearly the reason why
class Robot is not a subclass of Transform{}.
In the second, SELF indicates superclass node. ( as with SELF in VRML++ )
In this case, nodes A and B are not added to Robot. They are only used
in SELF's children field.
In this way, I think we may solve problems in single inheritance.
(Sorry again.)

2)
How about the following examples ??
(I think Stephan devised this idea in VRML++. But I couldn't understand
its meaning at first. Anyway.. Let's go. )

Transform --> BarTransform --> EqualTransform

CLASS BarTransform EXTENDS Transform
[ exposedField SFVec3f position 1 2 3 ] {
DEF SELF {
translation IS position
}
}

CLASS EqualTransform EXTENDS BarTransform
[ exposedField SFFloat distance 1 ] {
DEF SELF {
position IS distance distance distance
}
}

(Comment : To support this, the definition of sfvec3fValue shouldn't be as
sfvec3fValue : float float float
Rather, it should be as
sfvec3fValue : sffloatValue sffloatValue sffloatValue
)

or

CLASS EqualTransform EXTENDS BarTransform
[
public :
exposedField SFFloat distance 1
private :
field SFVec3f newpos distance distance distance
] {
DEF SELF {
position IS newpos
}
}

The problem in this approach is that we don't know whether we should
make 'position' field available in EqualTransform class or when
instantiating EqualTransform class.

3)
As a final example, let's consider 'Robot with hat on'.
# My poor English composition ability makes me prefer writing examples to
# explaining the idea.. :(

CLASS Robot EXTENDS Group [ exposedField SFFloat height 1 ] {
DEF SELF {
children [
Transform {...}
Transform {...}
...
]
}
}

CLASS HatRobot EXTENDS Robot [ exposedField SFFloat hatsize 0.5 ] {
DEF SELF {
children [
SELF.children
Transform {...}
]
}
}

How about :

CLASS HatRobot EXTENDS Robot [ exposedField SFFloat hatsize 0.5 ] {
SUPER {
children [
SELF.children
Transform {...} # uses hatsize and height
]
}
}

--------

I am sorry for my loose, vagrant, and dogmatic thinking.
I should have sticken to the problem on 'multiple inheritance'.
Please, understand that they are my opinion.

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
 Sungwoo Park, (Castle-Help Naive)
	homepage : http://compiler.kaist.ac.kr/~gladius
 	e-mail : gladius@compiler.kaist.ac.kr
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -