Re: Y Store /Closures

[Avi Bryant <address@hidden>]

On Fri, 28 Feb 2003, Sundar Narasimhan wrote:

> Avi -- Thanks for your post.
>
> >The effect this all has on the maintainability of the code base is
> >unbelievable.  And there is simply no way to get the same results
> >without either having first class continuations in your language, or
> >doing an automated transformation on all of your code to simulate them.
>
> What you seem to be talking about is simply maintaining and traversing
> session state, no? Most frameworks I've used (struts, zope etc.) have
> facilities for unwinding transactions and action chaining.

Action chaining - sure.  My point has to do with what this action chaining
specification looks like.  In Struts, you have a huge nest of XML
configuration files that lay out what the flow from one "action" to the
next is.  There is a *huge* difference between this and being able to
specify the flow in a full programming language.

What is the minimal piece of Java or XML or Python that shows the same
kind of executable step-by-step definition of a task as I gave in my post?

 (In fact,
> in some of our applications using the back button in the manner you
> suggest -- for example, after you've confirmed a purchase, would perhaps
> be frowned upon :)

Absolutely.  It's important to be able to easily specify where the
transaction boundaries are, and disallow backtracking across these
boundaries.  This is not very difficult to implement, and I use it all the
time.

> Have you looked at frameworks like these? And what do you think about
> them?

I have.  Not the same ballpark.  Again, the ability to specify the
workflow in a method, not a configuration file, is *not* a minor feature.

> It is much the same in some of these other frameworks.. but the added
> benefits are that you get a "map-in" from html forms/gui facilities
> (such as select boxes, trees, etc. -- i.e. "view" elements) to your
> objects at the "view" layer, automatic mapping to "actions"/mappings
> (which you can think of as mapping URL's to said function calls)
> automatic validation (i.e. what happens when the user types in "-x" for
> number of seats :) and map-out facilities. I agree w/ you about
> maintainability by the way, but there's other code to worry about too.
> I don't see continuations as important, helping to solve these
> problems or indispensable .. yet :)

Yes - all of that mapping and validation and so on is of course essential.
Actually, closures are extremely useful for what you call "map-in",
because you can associate a callback closure with each element as you
create it, but the same kind of thing can be done more clumsily without
them.  Although coming up with solid designs to handle these issues
is a large part of the work in building a good framework, and I certainly
spend a lot of time on them, they're not as interesting to me as
control flow, since there are a lot of good solutions out there
already (NeXT's WebObjects was probably one of the first to do this
well, way before Struts/Zope/etc, and still does it better than most).

> In classical client-server GUI programming/literature -- the point you
> raise was called the "event-driven vs. modal input" debate. We all
> know who won that one now, don't we .. :)

On the desktop.  The web is a very different environment, and modal input
(or, more accurately, backtrackable and forkable modal input) is indeed
the dominant paradigm.  The whole problem with most web app architectures
is that they're trying to use event-driven solutions (MVC) for modal
interfaces.

Avi