--------------446B9B3D794BDF3215FB7483
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> Park SungWoo wrote:
> >
> > My opinion is that the above PROTO A is just a collection
> > of two objects and that it is undesirable to treat it as
> > an object. (PROTO A actually declares two objects.)
> >
> > My solutions (that reside in my mind currently) are as follows:
> >
> > (1)
> > # note that eventOut is a set of eventIns in my proposal as
> > # in original OO-VRML.
> > CLASS A [ local exposedField SFFloat size 10
> > transparent field SFFloat radius
> > copy field SFTimeSensor clock
> > TimeSensor { fraction_changed SELF.set_size }
> > ] EXTENDS Cylinder {
> > height size
> > }
>
> So instead of having several objects in the body of
> a PROTO you suggest a kind of local variables (c.f.
> local variables/fields in SCRIPT nodes). I still don't
> like the OO-VRML way of 'Routing events" as in:
>
> TimeSensor { fraction_changed SELF.set_size }
>
> > (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'.
>
> 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 }
>
> > P,Q,R external attributes of A
> > P,Q internal attributes of B
> > Then, In another class D,
> >
> > CLASS D {
> > field SFA test ...
> > ...
> > # use test.P
> > # use test.Q
> > # use test.R
> > }
> >
> > Then, in
> >
> > DEF F D { test A }
> > DEF G D { test B }
> >
> > , object F works well, but object G doesn't work well.
>
> 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.
>
> 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
> ---------------------------------------------------------------
--------------446B9B3D794BDF3215FB7483
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <33CB4A5A.167EB0E7@cs.uni-sb.de>
Date: Tue, 15 Jul 1997 12:00:59 +0200
From: Stephan Diehl <diehl@cs.uni-sb.de>
X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.4 sun4m)
MIME-Version: 1.0
To: Park SungWoo <gladius@compiler.kaist.ac.kr>
Subject: Sungwoo's draft draft proposal
References: <199707121357.WAA06950@compiler.kaist.ac.kr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Park SungWoo wrote:
>
> My opinion is that the above PROTO A is just a collection
> of two objects and that it is undesirable to treat it as
> an object. (PROTO A actually declares two objects.)
>
> My solutions (that reside in my mind currently) are as follows:
>
> (1)
> # note that eventOut is a set of eventIns in my proposal as
> # in original OO-VRML.
> CLASS A [ local exposedField SFFloat size 10
> transparent field SFFloat radius
> copy field SFTimeSensor clock
> TimeSensor { fraction_changed SELF.set_size }
> ] EXTENDS Cylinder {
> height size
> }
So instead of having several objects in the body of
a PROTO you suggest a kind of local variables (c.f.
local variables/fields in SCRIPT nodes). I still don't
like the OO-VRML way of 'Routing events" as in:
TimeSensor { fraction_changed SELF.set_size }
> (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'.
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 }
> P,Q,R external attributes of A
> P,Q internal attributes of B
> Then, In another class D,
>
> CLASS D {
> field SFA test ...
> ...
> # use test.P
> # use test.Q
> # use test.R
> }
>
> Then, in
>
> DEF F D { test A }
> DEF G D { test B }
>
> , object F works well, but object G doesn't work well.
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.
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
---------------------------------------------------------------
--------------446B9B3D794BDF3215FB7483--