So here are two lists: one of points where we reached
a consensus and a list of open questions:
CONSENSUS (preliminary)
1) no overloading of prototypes (but maybe of eventhandlers!)
2) single inheritance
- CLASS keyword (so we can mix VRML 2.0 and our extensions)
- EXTENDS keyword
3) type system based on classes
- to prevent run-time errors
- to make restrictions more explicit
OPEN QUESTIONS
1) How does inheritance work, e.g.
- superclass instances are added to the
body of the PROTO (the VRML++ way)
- superclass instances are added
to the children field
- the really smart way, we have not yet thought of
2) Eventhandler and/or ROUTES
(I vote for the "and")
3) dynamic routing or an equivalent Eventhanlder concept
4) multiple inheritance or interfaces
(I vote for single inheritance with interfaces)
5) templates (as in C++)
- node types as parameters
PROTO p [ type X ]
{ X { }
}
6) macro mechanisms to define patterns like
where to put arms and legs in a prototype
- event names as parameters
7) EXTERNCLASS (problem how do you access default values,
which must be inherited from another file)
8) overloading of events (or eventhandlers), e.g.
PROTO Body [ eventIn SFNode addPart
eventIn Arm addPart
eventIn Leg addPart ]
{ #Eventhandler of addPart(SFNode n)
#Eventhandler of addPart(Arm n)
#Eventhandler of addPart(Leg n)
}
For each event, the most specific eventhandler
is chosen. (This is useful for implementing
Visitor design patterns)
9) abstract classes (ABSTRACT keyword): can not
be instantiated
10) "private" and "public" keywords for fields and
events: "private" properties are not inherited
by subclasses.
11) A hierarchy for the standard nodes
- should we have abstract classes
- MF and SF for nodes, eg. SFTransform, MFTransform
12) SELF and SUPER
- SELF: in combination with dynamic routing, SELF can
be used to create a ROUTE from the object itself to
an event of a node received as a field value or
by an event.
- SUPER: An Eventhandler X can detect that it is not
responsible to handle the received event and pass
it on to its superclass: SUPER.X
I hope we can come to a consensus for 1) to 4) soon.
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
---------------------------------------------------------------