Igor Bukanov wrote:
Sylvain Wallez wrote:
A minor remark though, about the syntax for creating the continuation. AFAICS, this is currently done with "Continuation()". I personally find it misleading, as the continuation represents the point where the current function was called, and not the point where the "Continuation()" statement occured.
Long ago, I proposed to Chris to allow a syntax suggested in [1] (2nd post) which is "arguments.continuation" which clearly relates the continuation to the point where the function is called, and he implemented it in [2] (search for "TokenStream.GETPROP").
Any use of "arguments" in Rhino is very expensive since it prevents fast access to variables in the function that uses that. In addition ECMAScript allows to alias arguments arbitrary or even to hide by local variable/parameter name so the way it is implemented in Cocoon version of Rhino just does not work. It is possible to do it properly but that would give code bloat.
IMO syntax is only nice if it allows a reasonable implementation without many corner cases. By that definition arguments.continuation is not nice while Continuation() is. Note if arguments would be a keyword in JS, the story would be opposite, but JS legacy takes its toll.
Ok, that makes sense, as I didn't knew about these constraints and limitations.
Plus function syntax allows to implement rather trivially optional arguments like amount of frames to capture. For example, suppose you want to define a function in JS that would behave exactly as Continuation() while adding a log about it. Then one could use something like:
function my_continuation() { log(); return Continuation(2); }
And then Continuation(0) would capture exactly at the point of invocation with Continuation() defaulting to Continuation(1). Note that I do not propose that, but rather argue that function syntax has its advantages as well.
Hey, that is a cool idea! Okay, let's keep Continuation() then.
This may seem as nitpicking, but if this is to go into the official Rhino and if Cocoon has to cope with minor incompatibilities like catch(continue|break|return), it would be good to have a clean syntax for continuations.
What do you think?
It is hard to implement catch(continue|break|return) correctly. For example, what should happen if an exception is thrown during the execution of code there or what if continuation is captured/restored inside the catch block? Depending on the situation the version in Cocoon would either throw an exception or go into infinite loop. AFAICS respecting "finally" has rather simple answers in all those corner cases and that is why I put efforts to implement it rather the catch blocks.
For compatibility a special mode can be added in principle to Rhino from mozilla.org with support for arguments.continuation and catch(...) with the clear marks about deprecation (unless, of cause, it is possible to implement the constructions simply and efficiently - then no deprecation!). But my continuation curiosity does not spread far enough to create such patch.
"arguments.continuation", AFAIK was never documented publicly, so we can safely forget about it. For the special catch syntaxes, there will be some compatibility problems as many people are likely to have used it. But since the use of "finally" seems to allow the same kind of behaviour with a simpler syntax and a clearly specified semantics, I think it is our job, we cocooners, to prepare our user base to this change and give them directions to upgrade their scripts.
We've been wanting for long to get rid of the rhino fork which, although it brought us an amazingly powerful way of building webapps, brought also a lot of community and legal issues. So we can consider that upgrading our scripts is the price to pay for being able to use the official Mozilla Rhino, and those that don't want to upgrade will just be asked to keep the current rhino fork.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
