I put nonterminals in <> and terminals in _ _ eg. _{_
<Class> ::= _CLASS_ <ClassName> _IMPLEMENTS_ <InterfaceName>*
_[_ <Property>* _]_
( _{_ _}_ | _{_ <Node> (<Node>|<Route>)* _}_ )
<Property> and <Node> are defined as in VRML 2.0,
<Route> is still under serious attacks
Note, that there is no SELF and no EXTENDS. Inheritance
will be implicit from the first node (The SELF keyword
might be useful later for other purposes as in VRML++).
We will need the case of an empty body of a class
definition, to define classes for the standard nodes.
These classes will inherit from SFNode, but will
implement different interfaces.
<Interface> ::= _INTERFACE_ <InterfaceName> _EXTENDS_ <InterfaceName>*
_[_ <InterfaceProperties> _]_
<InterfaceProperties> is similar to <Properties> but
no default values are allowed.
Sungwoo asked:
> Could you explain how we can solve the problem when there are
> more than one field with the same name in different interfaces ?
Because these fields have no default values, the only thing
we have to detect is, if they have incompatible types:
INTERFACE Mover [ field SFInt32 distance ]
INTERFACE Walker [ field SFFloat32 distance ]
INTERFACE Runner EXTENDS Mover, Walker [ ]
In this example we will get a type clash. On the other
hand, consider the next example:
INTERFACE Mover [ field Robot who ]
INTERFACE Walker [ field HatRobot who ]
INTERFACE Runner EXTENDS Mover, Walker [ ]
In this case there will be no type clash, but
Runner has to enforce the most restricive
type constraint of both interfaces, which
is HatRobot because HatRobot is a subclass
of Robot. So in this case the above is
equivalent to
INTERFACE Runner [ field HatRobot who ]
Sungwoo also asked:
> Okay. Then, what is the difference between Interfaces
> and Abstract Classes?
An interface provides no default values nor any implementation.
An abstract class might provide default values and
parts of implementations. So it might have an Eventhandler
which refer to nodes, which do not yet exist. It would
lead to a run-time error to instantiate this class.
A sub class could add these nodes and thus become
instantiable. But as we have interfaces I don't see
a need for abstract classes.
Next point: Sungwoo argued, that we don't need IS. I wonder,
what is the reason, that people use IS in VRML 2.0 at all?
Does someone have an example where it is not clear
without the IS, that a name used as a value
as in Transform { children set_children }
does refer to an eventIn?
-- 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
---------------------------------------------------------------