Judson Lester wrote:
>
> 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?
Good point.
Anyway, as long as those servlets are used as "actors" (mean they don't
return a stream, but beans), otherwise we'll end up having to parse this
stream to make it fit into the pipeline and then a ServletGenerators
would be much more handy for that (just like the JSPGenerator).
> 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.
I personally came to the conclusion that once you have continuations,
you get the power of servlet 'sessions' for free.
Using servlet API concepts might help those programmers who are already
used to servlets, but those (and are *MUCH* more out there!) that are
used to command line programming or GUI programming are not used to
'store data into some persistent object that flows across the sky'.
It took me a couple of days to explain what a 'servlet context' was to a
friend of mine who did programming for decades, but nothing on the web.
Sure, it could sound easier to you because you already know the
concept... also, if you had to work with previous web technologies, you
were probably delighted to see the concept of session implemented by the
servlet engine and not by your own code.
But at the same time, would it be even better if you didn't have to
think about it altogether and program like you'd do for your command
line?
> 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'll let Ovidiu reply to the specific example.
> 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.
Correct: in fact, you can implement what you want with sessions.
The real question is: is it be easier to program web-apps with
continuations than with sessions, as state maintainers?
I still have no idea, but, again, I think it's a promising idea and
definately worth investigating.
If, at the end, it comes out that it's easier to use sessions, we'll
happily forget about continuations.
Or the other way around.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
