cocoon-dev mailing list archives

Rereading that post in the context of later messages, it comes across much
more clearly, and a couple of thoughts occur to me.
One: in accepting the idea of a flowmap, are we committed to abandoning other
Servlets? Moreover, is there an advantage to avoiding the use of the Servlet
scopes (notably session scope)? (I'm led to this conclusion by the
"continuation identifier URLs" in Ovidiu's example) If not, what call is
there for return values in the flowmap?
For example, (from the continuation example)
function buy()
{
credentials = get-user();
ship-to-address(credentials);
charge-credit-card(credentials);
}
would there be anything wrong with
...
until(session.contains(credentials))
get-user();
ship-to-address(session.credentials);
....
(syntax is odd, but I think the idea comes across)
I recall criticisms about business logic in the flowmap, and encouraging the
use of Servlets in this way would help, I think.
Two:
The current description of the syntax of tail calls speaks to me of huge
call chains. The default behavior should usually not be to return to one's
caller, no? There might be points of flow that would be frequently revisted,
but they ought not be "returned" to. I'm reminded of the C/C++/Java
complaint of default fall-though being "wrong" in the majority of switch
statements. The analogy is that if flow falls off the end of a function, it
should return to the caller, which seems to me should usually be wrong.
Perhaps return should be allowed, but all returns should be explicit?
In the buy() example, oughtn't a> ship-to-address and charge-credit-card fall
more into Servlets? (Perhaps not entirely, but some portion...) and b> where
does buy() lead, eventually?
A corrolary of a required return keyword would be that a function would
declare itself returning (or a non-returning function be declared
"entry-point shopping-cart ()"), as a returning function would be an invalid
last call in a function.
I'd tentatively suggest that returns not be allowed, since it would be
incredibly difficult to implement logic in the flowmap without them. Of
course "continuations" as they exist in Scheme rely on them, but the idea of
an object to keep track of the current position doesn't strictly require a
call stack.
Judson
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org