DEF CLOCK TimeSensor { }
TouchSensor { touchTime CLOCK.startTime }
Why don't you write:
DEF TOUCH TouchSensor { }
TimeSensor { startTime TOUCH.touchTime }
The later would be close to calling the method "touchTime"
of the object TOUCH and use its value. The difference to
a method call in a programming language is, that this
is a "permanent" call. Whenever touchTime changes its
value so does startTime.
What I'd like this discussion to lead to, is a syntax
for methods with parameters which can be translated
into ROUTES and Scripts.
Cheers
--Stephan
Park SungWoo wrote:
>
> 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.
>
> 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.)
>
>
> 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
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -