> > (2)
> > The second solution, which I feel the better, employs ROUTEs.
> > CLASS A [ local exposedField SFFloat size 10
> > transparent field SFFloat radius
> > copy field SFTimeSensor clock TimeSensor { }
> > ] EXTENDS Cylinder {
> > height size
> > } ROUTE {
> > clock.fraction_changed TO set_size
> > }
> This is what I call 'dynamic routing' in the VRML++ proposal.
>
> So now we have these two ways of routing, but we have also
> constraints and I think, that routing is just a special
> case of a constraint, so we don't need routing at all:
>
> CLASS A [ local exposedField SFFloat size 10 IS clock.fraction_changed
> transparent field SFFloat radius
> copy field SFTimeSensor clock TimeSensor { }
> ] EXTENDS Cylinder {
> height size
> }
>
> I use the keyword IS to write 'one-way equality constraints'.
(1)
When an event is delivered to a field, the value of the field may be
updated accordingly. The ROUTE, whether it is specified by explicit
ROUTE keyword as in VRML or by OO-VRML routing mechanism, links an eventOut
to the field. In many situations, I think, there may be more than one
ROUTE routed to a field. For example, suppose that objects A,B,C can
handle the position of object D. Then, whenever an event is delivered to
object D regardless of the source object, the position of object D is
changed.
I think, therefore, ROUTE or OO-VRML way of eventOut-ing is necessary.
In your suggestion, class A (or object A) exploits clock.fraction eventOut
without the permission of object clock. This seems to violate the
desired relationship between objects.
> You suggest a keyword 'transparent' and I suggested
> 'hide' with an inverse semantics.
>
> In your above example I could not not instantiate
>
> A { height 30 }
>
> because height was not declared to be transparent. I think,
> one should use 'hide' to disallow a field to be inherited:
>
> CLASS A [ local exposedField SFFloat size 10 IS clock.fraction_changed
> hide field height
> copy field SFTimeSensor clock TimeSensor { }
> ] EXTENDS Cylinder {
> height size
> }
>
> Now A { height 30 } is still illegal, but because all
> fields are transparent by default, we can write
> A { radius 30 }
(2)
I am sorry but still confused.
My intention of 'transparent' keyword is that, if an external field
of a superclass is not declared as transparent in a subclass, then, it
becomes an internal field in the subclass.
In your example,
> CLASS A [ local exposedField SFFloat size 10 IS clock.fraction_changed
> hide field height
^^^^^^^^^^^^^^^^^
This seems to be unnecessary, for field 'height' without
transparent keyword becomes an internal field automatically.
> copy field SFTimeSensor clock TimeSensor { }
> ] EXTENDS Cylinder {
> height size
> We usually use type checking to detect whether a node
> has certain fields. But type checking assumes a monotonic
> type hierarchy with the property that every subtype
> has at least the fields of its supertype. With changing
> external fields into internal fields this is property
> does no longer hold. I don't think we need this
> kind of non-monotonic inheritance introduced by
> transparent.
(3)
I agree. My solution for the 'monotonic' inheritance property is
as shown in my previous mail. The idea is that we restrict field access
only to exposedField reading, and to eventIn/eventOut referencing (without
reading the content). For example, when exposedField X is an internal
field of object A, reading the current value of X causes no problem.
I will summarize my idea more formally. (but, It will be still informal)
Please, wait a few days.
Thank you very much.
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Sungwoo Park, (Castle-Help Naive) homepage : http://compiler.kaist.ac.kr/~gladius e-mail : gladius@compiler.kaist.ac.kr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -