1)
I think you are right, but I would like to correct some missing points.
(My argument in this section is not so important. It concerns only
with correct use of some terms.)
In your assertion,
1) A is a subtype of B <=> A has all properties of B
What happens if A or B has no properties ???
For example, consider the following demonstrative class hierarchy.
SFNode --- Geometry --- Box
--- Cone
SFNode --- Interpolator --- ColorInterpolator
Probably, both Geometry and Interpolator classes would have the same
properties as SFNode class. Hence, They could be used interchangeably
at least with respect to 'subtype'. However, we may feel confused if
someone says "Interpolator type is a subtype of Geometry type"
Hence, I think, it shows no hazard to employ only the notion of
'subclassing'.
> From 1) and 2) we infer that inheritance must
> preserve interfaces (properties). A subclass
> must provide all fields and events of its
> superclass. For multiple inheritance we get
> into trouble, more than one superclass can
> have for example event e. So do we inherit
> e from the first or the second superclass.
> This question comes from a programming language
> point of few. If we consider it from the
> VRML perspective, we might come to the conclusion
> that inherits both events (or Eventhandler in OOVRML).
> This is possible, because we can route the input
> event e of the new class to the input events e
> of its superclasses.
2)
Before proceeding, I'll compare Java and C++ with respect to multiple
inheritance.
In C++, we can use the idea of 'multiple inheritance'. Someone argued that
it would be very useful. However, I've never seen where a class inherits
multiple superclasses in actual programs, except in my first C++ primer book.
'Multiple inheritance' shows some dangerous, hard-to-understand, vague
situations. For example,
class A { public: int x; ...}
class B { public: int x; ...}
class C : public A, public B {... x = 3; }
The problem arises from the fact that two superclasses have a member with
the same name.
(It has been rumored that the C++ designers had decided to include
'multiple inheritance' in their specification in order to annoy C++
compiler designers, to make it hard to learn C++, to make complex the language)
Next, let's dive into Java. Java doesn't support multiple inheritance.
However, Java leaves some possibility to achieve multiple inheritance by
'implements' notion.
As you know, a Java class can extend only one super class, but can
implements more than one interfaces. That is, a class can inherits actual
implementations only from one superclass. It must provide its own
implementations for the abstract methods specified in implement-classes.
Now, back to VRML..
In my opinion, the trouble when we confronts by adopting multiple
inheritance in VRML is similar to the case for C++.
Suppose that class 'Body' extends classes 'Arm, Leg, Head'.
Arm ------
Leg -----+----- Body
Head ------
If Arm, Leg, and Head all have a field 'size', which has different
meaning according to the class, what happened when field 'size' is
assigned a value '1.0' in class Body ???
Also, how are the superclass objects positioned ?
Actually, if we want class 'Body' to inherit the three classes,
we may only have to define a new class such as,
CLASS Body [...] {
Transform {...
children [
Transform { ...
children [ Arm{...} ]
}
Transform { ...
children [ Leg{...} ]
}
Transform { ...
children [ Head{...} ]
}
]
}
}
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
automatically.
In summary, I don't find any good reason to support multiple inheritance.
I vote for drowning 'multiple inheritance'.
Then, how about 'implements' idea (in Java) ???
>
> I think the problem we have with inheritance is,
> that we would like to use it to compose graphical
> objects. But inheritance is to weak for this.
> Sungwoo's approach to put the superclasses
> into the children field of the subclass
> seems to be the outmost we can achieve. But
> it would restrict inheritance to Transform
> nodes.
3)
On 'putting the superclasses into the children field of the subclass':
For extending only one superclass, my idea is that the subclass is
ADDED to the superclass. it is different to putting the
superclass(es) into the children field of the subclass.
(In the above example, we should add the hat to the robot, but we
must not elect the hat as the owner of the robot.)
My point is that extending a class is usually intended to attach a
subsidiary or new (small) component to the class.
(Right ????)
>
> BTW on the homepage of our WG you can find
> a list of topics to discuss and a mail archive.
4)
WG = Working Group (or Woman Group ???)
BTW = what ???
>
>
> Cheers
> --Stephan
>
Let's discuss much MORE !!!
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Sungwoo Park, (Castle-Help Naive) homepage : http://compiler.kaist.ac.kr/~gladius e-mail : gladius@compiler.kaist.ac.kr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -