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.
