>
> Now assume that also the events would be parameters:
> PROTO OrientingTransform [
> field SFNode timeSensor NULL
> field SFNode orientationInterpolator NULL
> field SFNode transform NULL
> eventName out1 fraction_changed
> eventName in1 set_fraction
> eventName out2 value_changed
> eventName in2 set_rotation
> ] {
> Shape { #very bogus shape required by parsing
> }
> ROUTE timeSensor.out1 TO
> orientationInterpolator.in1
> ROUTE orientationInterpolator.out2 to destination.in2
> }
>
> On the other hand you could be more restrictive like
> in the connection class examples in VRML++, where
> the type system requires timeSensor to be of type TimeSensor:
>
> field TimeSensor timeSensor NULL
>
Yes, the way I would really like to specify it would be as you did above
with a strict type system.. the eventNames are optional here really, but
only because the Interpolator subclasses (as if they existed) all use
consistent names.
PROTO AnimationPattern [
field TimeSensor timeSensor NULL
field Interpolator interpolator NULL
field Transform transform NULL
eventName out1 fraction_changed
eventName in1 set_fraction
eventName out2 value_changed
eventName in2 set_rotation
] {
ROUTE timeSensor.out1 TO orientationInterpolator.in1
ROUTE interpolator.out2 to destination.in2
}
PROTO OrientingTransform extends AnimationPattern [
field OrientationInterpolator interpolator NULL
] {
}
Though suppose I were making a set of animation nodes that take an "on
event". There is no reason these would have to have a common base
class, so I would need to do something like the Java "interface":
public interface AcceptsOnSignal ...
class XXX extends WhatEver implements AcceptsOnSignal
either that or multiple inheritance. Otherwise, I would be stuck with a
hierarchy that doesn't fit with my AcceptsOnSignal concept.
Doing this sort of thing ("interface" types) seems to be where the
eventName feature becomes valuable. With my simple examples, the names
are (fortunately) already consistent.
The stricter type system seems like a requirement, you really don't have
alot flexibility in VRML 2.0 on what type of node goes where. Might as
well be obvious about it.
(... thanks for the suggestions and design patterns reference)
JJ