1)First, how do we know, that the event was defined
in one of the superclasses, how do we assure that
the definition of the superclasses is not changed.
If we declare the event, it will be added, in
case it was not present in one of the superclasses
and it will overwrite an inherited event, if
it was present in one of the superclasses.
That's exactly what happens in C++ or Java.
The discussion only arises in OO-VRML because
the declaration of the Eventhandler is
divided into two parts: the declaration of
the event in [ ... ] and the declaration of the handler.
We have a similar situation in VRML, there
the declaration of an event is divided into
the declaration in [ ... ], the ROUTEs (possibly global
and not local to the PROTO) and
the nodes the event is routed between.
2) In case we would allow overloading of Eventhandlers,
it would also no longer be clear, whether we
define a new case or overwrite an inherited one.
3) One can also overwrite inherited fields (and exposedFields
which are related to events). Fields have default
values and in the declaration in [ ... ] we can
overwrite the default values.
*** Inheritance ***
Sungwoo also suggested a way to "translate" inheritance.
The superclasses became nodes in the children field
of the new class. But this approach only works for
grouping nodes. Let me write this translation scheme in
an adhoc way:
CLASS c [ ... ] EXTENDS c1 .... cn { body }
---> PROTO c [ ... ] { Transform { children [ c1 { } ... cn { } body ]
} }
The problem with this approach is, that c is
no longer a subtype of c1 ... cn, unless
we require these to be subtypes of Transform.
The approach in VRML++ is less complex
(if we ignore at the moment how events and field values
are propagated to the superclasses). In VRML++ instances
of the superclasses are directly added to the body
of the PROTO. The related translation scheme:
CLASS c [ ... ] EXTENDS c1 .... cn { body }
----> PROTO c [ ... ] { DEF SELF c1 { }
c2 { } ... cn { } body }
This approach works well for accumulating behavior,
but is problematic for combining geometries, there Sungwoo's
suggestion is superior. But I would prefer the simpler
approach of VRML++, so we don't get into problems
with the type system. But in addition I'd like to
add a concept similar to templates in C++.
With these templates we could express the above
translation schemes, Johannes Johannsen's patterns,
and hopefully much more, e.g. how to construct
an avatar given the types of its parts: head, leg,
body, arms.
-- 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
---------------------------------------------------------------