cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Michels <step...@apache.org>
Subject Re: Scheme Continuations vs Brakes Continuations was Re: Groovy support in Cocoon
Date Tue, 06 Apr 2004 10:12:00 GMT
Am Mo, den 05.04.2004 schrieb Christopher Oliver um 22:44:
> >Why don't use (Object obj, Method method, Object[] args) in the
> >constructor of the continuation object.
>
> That's a possible alternative, but makes prevents making Continuation an 
> abstract class.

Why should the continuation be abstract? The idea of the brakes people
was to create something similar to java.lang.Thread

Thread t = new Thread(new Runnable() {
  void run() {
    sendPage("a");
    wait();
    sendPage("b");
  }
}); 
t.start();


> >Continuation.SUICIDE.invoke(null); ?
> >
> >*you see many question marks over my head*
> >
> >I hope you have patience with me :)
> >
> >  
> >
> The idea of SUICIDE is that it has the effect of unwinding the stack but 
> not executing any further code and directly returns to the entry point 
> (i.e. it is the continuation of the end of some code ). For example (in JS):
> 
> var suicide;
> 
> function f() {
>    suicide = arguments.continuation;
> }
> 
> f();  // <== since there's no code to execute after f(), invoking 
> suicide later will have the effect of simply terminating the script.
> // end of script
> 
> 
> In the current Rhino implementation creating a Continuation in a 
> top-level script has the same effect (since what comes after the end of 
> the script is - nothing).
> 
> This behavior is as in Scheme.

Hmmm, not every intuitive. So your f() has the same role like
Continuation.suspend() ?

With call of suspend() the Continuation goes from the State "restoring"
into State "!restoring & !capturing", and in cases of the 
state "!restoring & !capturing" into the state "capturing".

Stephan.


Mime
View raw message