1. Event handler
The main reason for introducing event handlers is
to ensure that the behavior of a node 'MUST' be described completely
in its node definition or its prototype definition.
Actually, this can be achieved easily in VRML as follows:
# in VRML 2.0
PROTO T [...] {
DEF X Some_Node {...}
...
DEF Y Script {...}
...
ROUTE Y.out to X.in
}
However, if a Script node P controls a node Q, then P and its relevant
ROUTEs may be placed anywher in the VRML file. Hence, this approach may
decrease object-orientedness sometimes.
In OO-VRML, the event handler(OO-VRML's Script object) 'MUST' be
included in the prototype definition.
That is, the reason for introducting event handlers is to increase
its object-orientedness. (Is my opinion right ????)
If event handlers are adopted for OO-VRML, then ROUTEs are also unnecessary.
In other words, eventOuts in OO-VRML take place of ROUTEs in VRML.
To my knowledge, the concept of ROUTE was devised in 1950's before
the concept of object-orientation was established systematically. (Right ???)
Since the eradication of Script nodes and ROUTEs is a radical change in VRML,
I think that our working group members should discuss much more whether
Script nodes should be preserved or not to increase object-orientation.
2. ROUTE
I guess that almost every VRML system developer does not employ ROUTEs
in the implementation in order to increase efficiency.
Hence, they probably do not use Script nodes, either.
They may substitute well-designed internal functions for Script nodes.
In OO-VRML paper, I argued that the number of event transmissions in
OO-VRML-based system had decreased. But it is implementation-dependant.
(I mentioned this point in VRML '97 presentation. Anyway I dislike ROUTEs
because they are sometimes extremely confusing.)
> A special question to Sungwoo: Why do you have eventIns
> as values of eventOuts and not vice versa? My impression
> would be, that having an eventIn as the value of an eventOut
> is close to calling a method an using its result.
>
>
> -- Stephan
3. eventOuts and eventIns
As you know, an eventOut is connected to one or more ROUTEs in order to be
useful in VRML world. If we do not use ROUTEs (in OO-VRML for my case),
we can put the destination eventIns directly in the eventOut. Why should
we bother to employ ROUTEs again ???
For 'not vice versa', I don't understand exactly your intention.
But I think that, for a node to be object-oriented, it only has to know
its input value and determine corresponding behavior. It does not need to
know from where to receive events.
Any arguments welcomed !!!
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Sungwoo Park, (Castle-Help Naive) homepage : http://compiler.kaist.ac.kr/~gladius e-mail : gladius@compiler.kaist.ac.kr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -