cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <>
Subject Re: Scheme Continuations vs Brakes Continuations was Re: Groovy support in Cocoon
Date Tue, 06 Apr 2004 16:18:10 GMT
Stephan Michels wrote:

>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
Primarily to hide the implementation details, but this is not a big issue.

> <snip>
>>This behavior is as in Scheme.
>Hmmm, not every intuitive. So your f() has the same role like
>Continuation.suspend() ?
Yes. Although it may seem unintuitive at first glance, there is a long 
and well-known history of continuations in Scheme. We should try to 
follow that model if possible, IMO.

BTW, I started playing around with BCEL and your code (mostly debugging 
VerifyErrors whenever I try to add anything... ;)). One serious problem 
I noticed is that we can never allow calls through reflection in the 
call chain that leads to creation of a continuation - because 
java.lang.reflect.Method.invoke() is not and cannot be instrumented. I 
know Rhino has the capability to generate "Invoker" classes at runtime 
to replace reflection calls with direct compiled calls 

These "Invoker" classes _could_ be instrumented and therefore used in a 
continuation. However, some changes to Rhino would be required I think, 
because these classes are loaded by a Rhino-internal class loader so 
there's no opportunity to instrument them. I don't know if Groovy or 
Jython use reflection. If so, a similar approach to Rhino's "Invoker" 
could be used there also.



View raw message