Re: [Oopic-compiler-devel] more of 'background' ala Dan Sandberg

[Yahoo J. <Yah...@mc...>]

Neil,

> But what would "background" actually mean to the function?  The OOPic
can't
> execute these functions in the background, so it could be misleading.

The 'background' would be nothing more than a script syntax to clearly
identify that this bit o' script is (part of) a virtual circuit.  Perhaps
another token could be used, such as 'virtual_circuit'.  The thought is to
clearly seperate in the syntax the VC stuff from the slower scripted stuff.
That division would have helped me grasp the VC concept sooner; maybe it
would help others too (I'm recalling Scotts comment that at Trinity
Firefighting none of the OOpics were using VC).

> Are you suggesting that basically the above example would translate into
an
> oWire and an oEvent, triggered by the button press?  If so, then it's a
> nice idea, and cleans up the messy way you have to wire up oEvents.

I'm not sure at all about whether I mean that.  <grin>  I'm a VC novice.

I actually was looking for a possible syntax to seperate VC from the rest.


> The thing I dislike about this syntax is that the use of "background"
> implies that the first statement in the function must be an "if", which
> seems a bit kludgey to me.  Unless I'm misunderstanding you.

Your event_table idea is attractive.

Would there be (asks the VC ignorant guy) situations where a VC would simply
need to be setup and it runs autonomously?  Even then, I suppose that an
.Operate interface might be required/desired.

Daniel




----- Original Message -----
From: "Neil Durant" <nd...@us...>
To: <oop...@li...>
Sent: Wednesday, 05 May 2004 22:31
Subject: Re: [Oopic-compiler-devel] Re: [oopic] Re: Oopic compiler issues -
The low down.


> > Dan Sandberg wrote:
> >> With the THEORETICAL syntax I was mentioning earlier,
> >> combined with the kinda of objects that the OOPic
> >> already supports, we could do something like this:
> >>
> >> background void activateSolenoid() {
> >>      if ( button.pressed ) {
> >>          solenoid = true;
> >>          solenoidTimer = 5;
> >>          solenoidTimer.operate = true;
> >>      }
> >> }
> >> background void deactiveateSolenoid() {
> >>      if ( solenoidTimer.operate and solenoidTimer == 0 ) {
> >>          solenoid = false;
> >>          solenoidTimer.operate = false;
> >>      }
> >> }
>
>
> D. Daniel McGlothin wrote:
> > The more I think about Dan Sandberg's idea, I like it.
> >
> > The notation of 'background' as an attribute of the routine is
essentially
> > what I was thinking of with my Delphi unit 'sections' approach.
>
> But what would "background" actually mean to the function?  The OOPic
can't
> execute these functions in the background, so it could be misleading.
>
> Are you suggesting that basically the above example would translate into
an
> oWire and an oEvent, triggered by the button press?  If so, then it's a
> nice idea, and cleans up the messy way you have to wire up oEvents.
>
> The thing I dislike about this syntax is that the use of "background"
> implies that the first statement in the function must be an "if", which
> seems a bit kludgey to me.  Unless I'm misunderstanding you.
>
> Another alternative would be to use an "event table", which would work a
> bit like the message map system in MFC, if you've used MFC.  Basically
> syntax along these lines (either transformed by preprocessor or within the
> compiler itself):
>
> EVENT_TABLE
> {
>     LINK(button.pressed, activateSolenoid)
> }
>
> void activateSolenoid()
> {
>   solenoid = true;
>   solenoidT8mer = 5;
>   solenoidTimer.operate = true;
> }
>
> ...which would link "button.pressed" to a function (oEvent handler) called
> activateSolenoid.  The first parameter of the LINK macro would be an
> attribute of a named object.
>
>
> The problem is that translating stuff into oEvent handlers will only work
> if the "if" clauses can be easily converted into virtual circuits, and so
> the whole thing can operate in the "background".  If the "if" clause
relies
> on scripting language expressions, then it would be non-trivial to make it
> an entirely backgrounded piece of code.
>
> Neil
> --
> Neil Durant
> <nd...@us...>