On Wed, 19 Dec 2001 13:41:58 -0600, Judson Lester <[EMAIL PROTECTED]> wrote:
> > > 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. > > And more. You are no longer responsible for the store-and-retrieve part of > session management, variables are either assigned or not, etc. That's exactly right! > > 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? > > Being able to avoid the management of the session would help a lot. > And yes, minimizing the amount of new pardigm to be learned would > make everything gravy. Putting desktop developers in a position to > quickly be coding web apps is veryt attractive. The biggest difference from a normal programming language are these hidden non-local exits, which are somewhat equivalent to a goto instruction. It's quite a tricky, yet powerful mechanism. > > > 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 disagree. I think <emp>a</emp> real question is ease-of-use. > > Another, equally valid question is what will emphasize SoC, and keep > business logic in its place (with the subquestion: what relationship > do flow and business logic have? I propose that they are not > identical, and that their intersection should be limited to flow's > dependance on business logic)? If variable assignment must come > from Java code, because flow units can't return anything, it becomes > very difficult to use flowmaps for business logic. I argue that we do need to have functions that return values. I've shown in a previous message how such functions are useful. The distinction between flow and business logic is a bit blurry, and I would say it's probably not a good idea to remove functionality from the language just to enforce separation of concerns. Why should a calculator application for example need to use Java to do it's logic, when the flow logic can do additions and substractions? I think we should let the developer choose the right mix he/she wants. This may lead to messy programs in the beginning, but with the right patterns explained to people, I think it's easier for people to write using the right mix. > > If, at the end, it comes out that it's easier to use sessions, we'll > > happily forget about continuations. > > Reflection leads me to ask, though: is the idea I'm suggesting of > continuation-based "flow units" (I have a hard time thinking of them > as "functions" without returns) differ significantly from FSM/goto > programming? The difference I can see is that state transitions are > seperated from input, which is fairly significant in my mind, and > almost exactly what is wanted. The way I see the non-local exits of the functions with no return, is that they take the program out the current context. It's like doing a system.exit(), and starting from a different place. It is more like forcing the program take on a different flow, than moving to a different state. Or at least this is how they should be used, and I believe you can enforce this model by giving programmatic access only to the current continuation, not to the past ones. This way the programmer cannot jump to an arbitrary existing continuations, only to the last one, which will resume the execution of the program. This avoids the goto stigma, where you can have jumps to different parts of the program. Best regards, -- Ovidiu Predescu <[EMAIL PROTECTED]> http://orion.rgv.hp.com/ (inside HP's firewall only) http://sourceforge.net/users/ovidiu/ (my SourceForge page) http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
