<path> ::= SELF.<simplepath>
| SUPER.<simplepath>
<simplepath> ::= <fieldname> | <eventname>
| <fieldname>.<simplepath>
| <eventname>.<simplepath>
in ROUTEs and as values of fields. Note, that
the PARENT keyword is omitted because it seems
difficult because of multiple parents and
in many cases there is a work around by
explicitly naming the parent using DEF.
But when we add constraints (i.e. formulas,
functions as parts of paths) and allow
broken links and ...
I am not sure this can be implemented
efficiently. First we would have as the
value of **every** field a special datastructure
containing its value and a list of
constraints for this field and a list
of constraints depending on this field.
Another point is, that I don't want to trade
CLASSES and a static type system for constraints.
I aggree, that we should add Amulet's 4 ways of inheritance:
INHERITED, COPY, SHARED and LOCAL
I expect, that these can be easily implemented.
BTW do we aggree on these point:
1) Our extensions should be implementable with
the VRML 2.0 and Java-Scripting
2) An author should be allowed to use VRML 2.0
syntax in class definitions, this also implies
that he is allowed to use ROUTEs
The author should be allowed to mix VRML 2.0
prototypes and our classes.
The 2nd point is important. Our extensions should provide
better means to express what ROUTEs can be used for,
but we shouldn't remove ROUTEs. In other words we
are talking about "extensions" not "changes" of VRML 2.0
This important for our extensions to be accepted by
a wide audience and to allow authors to gradually
change their style of writing virtual worlds.
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
---------------------------------------------------------------