@INPROCEEDINGS{ Cardelli:84,
AUTHOR = "Luca Cardelli",
TITLE = "Compiling a Functional Language",
BOOKTITLE = "International Symposium on LISP and Functional
Programming",
YEAR = "1984"
}
@article(Cardelli_Wegner:85,
author = {L. Cardelli and P. Wegner},
title = "{On Understanding Types, Data Abstraction and
Polymorphism}",
journal = "{ACM Computing Surveys}",
volume = "17(4)",
year = 1985
)
Here subtyping is a structural property, i.e. the type
of an object can be determined by looking at its interface.
Two objects with the same interface have the same type,
So we might say if we look at a node
- that it has a structural type (in the above sense)
- it has a type (in the VRML 2.0 sense)
- it has class
If the subclass relation preserves the structural
subtype relation then we know, that each object
of a subclass has all the properties of its
superclass.
Sungwoo wrote:
> What happens if A or B has no properties ???
Then A and B have the same structural type,
but they can belong to different classes.
Sungwoo wrote:
> In summary, I don't find any good reason to support multiple
> inheritance.
I think it is great to combine behaviors:
CLASS Robot EXTENDS Walker, Runner, Talker
{ ... }
Here every object of class Walker knows the
event "walk", every object of class Runner
the event "run", ...
On the other hand, you could argue, that these
usually have to be reimplemented in Robot,
so it would be enough to define interface Walker, Runner,
and Talker.
In summary, I think single inheritance with interfaces
as in Java provides a good type system while it prevents
us from many problems of multiple inheritance, including
those mentioned by Sungwoo.
Single inheritance would be to weak. How could we express,
that something is a Grouping and a Child node?
JJ and Sungwoo have already presented some hierarchies
for standard node types of VRML 2.0. In the distribution
of VRML++ there is a file standardClasses.vpp which
defines the standard nodes as VRML++ classes using
abstract classes like AbstractSensor or AbstractGroup.
All these suggestions have much in common, but
are not yet complete. On pages 260 and 261 in
the "VRML Handbook" by Wernecke and Hartman
you can find two graphs which depict the type
restrictions on fields of standard nodes.
I don't believe, that distinguishing SFTransform
and MFTransform in the class hierarchy,
is a good idea.
I would make SF and MF parts of the syntax
for type restrictions. So SFTransform and Transform
are equivalent, while MFTransform means one or
more nodes, which have to belong to Transform
or one of its subclasses are allowed. In other
words every class C induces a type SFC and MFC.
CLASS X [ eventIn MFTransfrom nodes
eventIn Transform next
eventIn SFTransfrom previous ]
Here the declaration of next and previous are
equivalent.
But definetely part of our proposal must be
a class hierarchy for standard nodes. If we have
reached a consensus on inheritance (see my next
mail). Is there someone willing to
encode a preliminary hierarchy in the new
syntax? Any volunteers? You could use the
above mentioned VRML++ file as a starting
point. So you don't have to enter CLASS
definitions for all the special nodes
without any interesting type restrictions.
BTW "BTW" means "by the way".
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
---------------------------------------------------------------