cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Judson Lester <>
Subject Re: [RT] Managing Flow and Resources
Date Wed, 19 Dec 2001 02:57:22 GMT
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();

would there be anything wrong with


(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.

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.


To unsubscribe, e-mail:
For additional commands, email:

View raw message