--------------167EB0E72781E494446B9B3D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
SungWoo asked me to forward this mail to the list:
Park SungWoo wrote:
>
> Hello,
>
> >As your are in the process of writing the specification,
> >there a still many points missing, e.g. the syntax of
> >constraints.
>
> Right. I will mention other points missed in the specification soon.
> I've already summarized the points in my notebook, and have to
> write in the specification.
> Please, wait for a few days. (My first thesis seminar was over last Thursday.)
>
> >You write:
> >" Any incoming event for the field are ignored because
> > only the constraint is used to determine its value. "
> >
> >I don't think, this is the way it should work. I expect,
> >that there could never be the case that an event is
> >routed to a field and a constraint is attached
> >to a field at the same time. A route would remove
> >the constraint and vice versa, depending on which
> >one is created last.
>
> You told that 'there could never be the case that an event is
> routed to a field and a constraint is attached to a field at the same time'.
> Suppose that field A is given a constraint as its content.
> The programmer will not usually route events to the field.
> Hence, my suggestion is that those events are ignored.
> In other words, the system processes constraints of the all objects first.
> Then, it tries to process events, (that is, to execute event handlers.)
> Those fields that are updated by constraints are not affected by
> event handlers.
>
> If I missed your points, please, let me know.
>
> >
> >If I understood the syntax of class declarations right,
> >there is no body of a class definition where one
> >could just add node instances. I try to make this
> >point clear by giving an example:
> >
> >in VRML 2.0
> >
> >PROTO A [ field SFFloat size 10 ]
> >{ DEF CYL Cylinder { height IS size }
> > DEF CLOCK TimeSensor { }
> > ROUTE CLOCK.fraction_changed TO CYL.size
> >}
> >
> >in your syntax there is no place to define the TimeSensor:
> >
> >CLASS A [ field SFFloat size 10
> > transparent field SFFloat radius
> > ... and all other external fields of Cylinder
> > ]
> >EXTENDS Cylinder
> >[ height size ]
>
> 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
> }
>
> In this solution, keyword SELF has a special meaning. It references to the
> object that is defined in the current context; hence, it can only appear
> inside an CLASS definition.
> From the above CLASS definition, two objects are created. The one is
> object A, and the other is a TimeSensor object.
>
> Suppose that a new object B is created from class A.
>
> DEF B A { size 20 }
>
> In this case, by the definition of mode 'copy' for node pointers,
> another TimeSensor object is created. We, of course, want the TimeSensor
> object to be related with the new object B, not A.
> This is achieved by keyword SELF. If we replaced SELF with A as follows,
> an abnormal result arises.
>
> CLASS A [ local exposedField SFFloat size 10
> transparent field SFFloat radius
> copy field SFTimeSensor clock
> TimeSensor { fraction_changed A.set_size }
> ] EXTENDS Cylinder {
> height size
> }
>
> In summary, SELF enables the relative node-pointing mechanism in CLASS
> definition.
>
> (2)
> The second solution, which I feel the better, employs ROUTEs.
> I am thinking about whether we should allow ROUTEs or not.
> My opinion goes toward accepting ROUTEs.
> (I've missed the explanation on ROUTEs in the specification.)
>
> 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
> }
>
> In the above suggestion, the ROUTE defines an 'internal' route.
> That is, the relative relation of the route with A and TimeSensor objects
> are kept even when class A is instantiated afterwards.
> (My explanation is insufficient, but, I think you can understand it.)
>
> I wish your comments and suggestions for this matter.
>
> >
> >There is another problem with this syntax, namely that
> >one has to declare every inherited field transparent.
> >Usually in OO fields are accumulated by inheritance
> >and in your terminology all inherited external fields
> >of a superclass become external fields of the subclass.
> >
> >Consider the following example:
> >
> >CLASS A
> >CLASS B EXTENDS A
> >CLASS C EXTENDS B
> >
> >If we add a field f to A we would have to add "transparent"
> >declarations into B and C. Eventually it leads to huge
> >class definitions consisting mostly of transparent declarations,
> >e.g. the definitions in the VRML97 paper of Curtis Beeson.
> >So I would suggest a keyword hide which would do exactly
> >the opposite of transparent. hide would turn an inherited
> >external field into an internal one.
>
> I am sorry but I don't understand what 'hide' keyword is expected to do.
> Please, send your more detailed explanation on 'hide'.
>
> I think you want to mention the accessibility of fields or eventIns in
> subclasses. Right ??? I will try first to explain what you think
> the problem is.
>
> In the above example, suppose that A has external attributes P,Q,R.
> In class B, P,Q become internal attributes, and cannot be accessed from
> outside.
> 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.
>
> For the solution of this problem, I devised the following strategy.
> 'If node pointer P is available, and P points to object Q,
> then, we can read Q's exposedFields (whether they are interal or external),
> acccess Q's eventIns and eventOuts (for ROUTEs and others).
> ('accessing' is far different from 'reading')
> That is, an internal field cannot be given new content, but,
> an internal exposedField can be read from outside. This arises no problem to
> my knowledge.
> The same idea can be applied to EventIns and eventOuts as well.
>
> Thank you for your helpful suggestion.
> I will post a revised mail after I write the specification more.
>
> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Sungwoo Park, (Castle-Help Naive)
> homepage : http://compiler.kaist.ac.kr/~gladius
> e-mail : gladius@compiler.kaist.ac.kr
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------
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
---------------------------------------------------------------
--------------167EB0E72781E494446B9B3D
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Received: from sol.cs.uni-sb.de (iWvifSDvMfOjEhb99ccf+f1TU0nLQmHq@sol.cs.uni-sb.de [134.96.252.20])
by gigasun.cs.uni-sb.de (8.8.6/97052600) with ESMTP
id PAA13643 for <diehl@gigasun.cs.uni-sb.de>; Sat, 12 Jul 1997 15:59:24 +0200 (CEST)
Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.252.31])
by sol.cs.uni-sb.de (8.8.6/97052600) with ESMTP
id PAA07773 for <diehl@sol.cs.uni-sb.de>; Sat, 12 Jul 1997 15:59:23 +0200 (CEST)
Received: from compiler.kaist.ac.kr (compiler.kaist.ac.kr [143.248.172.8])
by cs.uni-sb.de (8.8.6/97052600) with SMTP
id PAA26549 for <diehl@cs.uni-sb.de>; Sat, 12 Jul 1997 15:59:18 +0200 (CEST)
Received: (from gladius@localhost) by compiler.kaist.ac.kr (8.6.12h2/8.6.9) id WAA06950 for diehl@cs.uni-sb.de; Sat, 12 Jul 1997 22:57:30 +0900
From: Park SungWoo <gladius@compiler.kaist.ac.kr>
Message-Id: <199707121357.WAA06950@compiler.kaist.ac.kr>
Subject: Re: Still Alive - 002
To: diehl@cs.uni-sb.de (Stephan Diehl)
Date: Sat, 12 Jul 1997 22:57:30 +0900 (KST)
In-Reply-To: <33C6373E.3F54BC7E@cs.uni-sb.de> from "Stephan Diehl" at Jul 11, 97 03:38:07 pm
X-Mailer: ELM [version 2.4 PL21-h4]
Content-Type: text
Hello,
>As your are in the process of writing the specification,
>there a still many points missing, e.g. the syntax of
>constraints.
Right. I will mention other points missed in the specification soon.
I've already summarized the points in my notebook, and have to
write in the specification.
Please, wait for a few days. (My first thesis seminar was over last Thursday.)
>You write:
>" Any incoming event for the field are ignored because
> only the constraint is used to determine its value. "
>
>I don't think, this is the way it should work. I expect,
>that there could never be the case that an event is
>routed to a field and a constraint is attached
>to a field at the same time. A route would remove
>the constraint and vice versa, depending on which
>one is created last.
You told that 'there could never be the case that an event is
routed to a field and a constraint is attached to a field at the same time'.
Suppose that field A is given a constraint as its content.
The programmer will not usually route events to the field.
Hence, my suggestion is that those events are ignored.
In other words, the system processes constraints of the all objects first.
Then, it tries to process events, (that is, to execute event handlers.)
Those fields that are updated by constraints are not affected by
event handlers.
If I missed your points, please, let me know.
>
>If I understood the syntax of class declarations right,
>there is no body of a class definition where one
>could just add node instances. I try to make this
>point clear by giving an example:
>
>in VRML 2.0
>
>PROTO A [ field SFFloat size 10 ]
>{ DEF CYL Cylinder { height IS size }
> DEF CLOCK TimeSensor { }
> ROUTE CLOCK.fraction_changed TO CYL.size
>}
>
>in your syntax there is no place to define the TimeSensor:
>
>CLASS A [ field SFFloat size 10
> transparent field SFFloat radius
> ... and all other external fields of Cylinder
> ]
>EXTENDS Cylinder
>[ height size ]
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
}
In this solution, keyword SELF has a special meaning. It references to the
object that is defined in the current context; hence, it can only appear
inside an CLASS definition.
From the above CLASS definition, two objects are created. The one is
object A, and the other is a TimeSensor object.
Suppose that a new object B is created from class A.
DEF B A { size 20 }
In this case, by the definition of mode 'copy' for node pointers,
another TimeSensor object is created. We, of course, want the TimeSensor
object to be related with the new object B, not A.
This is achieved by keyword SELF. If we replaced SELF with A as follows,
an abnormal result arises.
CLASS A [ local exposedField SFFloat size 10
transparent field SFFloat radius
copy field SFTimeSensor clock
TimeSensor { fraction_changed A.set_size }
] EXTENDS Cylinder {
height size
}
In summary, SELF enables the relative node-pointing mechanism in CLASS
definition.
(2)
The second solution, which I feel the better, employs ROUTEs.
I am thinking about whether we should allow ROUTEs or not.
My opinion goes toward accepting ROUTEs.
(I've missed the explanation on ROUTEs in the specification.)
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
}
In the above suggestion, the ROUTE defines an 'internal' route.
That is, the relative relation of the route with A and TimeSensor objects
are kept even when class A is instantiated afterwards.
(My explanation is insufficient, but, I think you can understand it.)
I wish your comments and suggestions for this matter.
>
>There is another problem with this syntax, namely that
>one has to declare every inherited field transparent.
>Usually in OO fields are accumulated by inheritance
>and in your terminology all inherited external fields
>of a superclass become external fields of the subclass.
>
>Consider the following example:
>
>CLASS A
>CLASS B EXTENDS A
>CLASS C EXTENDS B
>
>If we add a field f to A we would have to add "transparent"
>declarations into B and C. Eventually it leads to huge
>class definitions consisting mostly of transparent declarations,
>e.g. the definitions in the VRML97 paper of Curtis Beeson.
>So I would suggest a keyword hide which would do exactly
>the opposite of transparent. hide would turn an inherited
>external field into an internal one.
I am sorry but I don't understand what 'hide' keyword is expected to do.
Please, send your more detailed explanation on 'hide'.
I think you want to mention the accessibility of fields or eventIns in
subclasses. Right ??? I will try first to explain what you think
the problem is.
In the above example, suppose that A has external attributes P,Q,R.
In class B, P,Q become internal attributes, and cannot be accessed from
outside.
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.
For the solution of this problem, I devised the following strategy.
'If node pointer P is available, and P points to object Q,
then, we can read Q's exposedFields (whether they are interal or external),
acccess Q's eventIns and eventOuts (for ROUTEs and others).
('accessing' is far different from 'reading')
That is, an internal field cannot be given new content, but,
an internal exposedField can be read from outside. This arises no problem to
my knowledge.
The same idea can be applied to EventIns and eventOuts as well.
Thank you for your helpful suggestion.
I will post a revised mail after I write the specification more.
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Sungwoo Park, (Castle-Help Naive) homepage : http://compiler.kaist.ac.kr/~gladius e-mail : gladius@compiler.kaist.ac.kr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
--------------167EB0E72781E494446B9B3D--