Stefano Mazzocchi <[EMAIL PROTECTED]> writes: <snip on intro/>
> Marc is advocating that "there is more than just > continuation-based flow control" and he is dead right: there > are as many ways to implement flow control as there are stars > in the sky. > > But there are two major families of approaches: procedural > vs. declarative. > > The continuation-based flow is procedural. What Marc is > proposing in his wiki page is declerative. state oriented. in > short, it's a FSM. it's the "goto" equivalent for the web. I'd respectfully disagree. The two models are (or should be) more like procedural and functional. Functional does not have to be state oriented. I'm not sure I can make the distinction clear, but again this comes back to the issue I keep raising: a rule based evaluation vs. a procedural evaluation can both achieve exactly the same thing. Rules may appear to be declarative, but only in the sense that the statements of a procedural language are declarative. The difference is that instead of doing dynamic evaluation of the data you are doing dynamic evaluation of something that is more abstract (ugh); a mapping of data to logic. Consider for a moment creating a flow graph as an XML document. Cycles have to be handled via refid (or similar) but otherwise it's straightforward not? Once you have it you can combine it with any other context information. At that point running an Xpath over the combined context to evaluate the next step is a functional evaluation of the next step ( as opposed to a procedural if then else block evaluation of the next step ). > I'm sorry, but I cannot stop considering this harmful. or, at > least, a poor substitute (for this kind of usage) for what we > achieved with continuation-based produceral flow descriptions. I'm not sure that allowing alternative approaches is a good thing at this point. However, I don't see how some abstraction hurts? Having said that, I ran across this on the xml-dev list this morning: http://www.eskimo.com/~jeremyk/archives/000078.html The quote that caught me eye "Extensibility makes abstraction expensive." is perhaps particularly relevant to this question? However, the converse -- abstraction makes extensibility expensive" is not necessarily always true... <small snip/> > Sylvain likes abstactions. Otherwise the sitemap interpreter > would be called SitemapInterpreter instead of TreeProcessor. > > I used to love abstractions as well. > > Now I'm far more concerned about them: less is more. That's the good thing about abstractions: they have less semantic baggage than a specific implementation. Or to put it another way, one good abstraction can replace a dozen more concrete specifications... > Cocoon is powerful because there is *ONE* sitemap semantics > and my continuous obstructionism to the pluggability of > sitemap semantics forced discussions to happen, that created > community and focused development. > > The sitemap and the flow are the core of Cocoon. Abstracting > them will balkanize the cocoon community. Huh? Pipeline, Generator, Map(!) and friends are highly abstract in the Cocoon context! They happen to be good analogies to concrete real life things, but they have nothing to do with the real life things. Cocoon works because it has good abstractions (that people can understand) not because it doesn't have abstractions! I think you're on the wrong track here... > I'm *strongly* +1 to anything that will force discussion and > improve the existing ideas (as we did with the sitemap > semantics over the years and as we did with the FOM recently). Appreciated, I'm not trying to be dismissive or argumentative here. As I discussed with you when the flow sitemap integration discussions where in full swing I do have a long term agenda (XSLT managed flow) and I would like to see a way of including it in Cocoon without breaking existing functionality... <snip> > We choose one direction for our core and we keep evolving > that. No polymorphism just because a few people have legacy > they want to reuse, it's not our problem. That makes sense. I'll note that abstraction and polymorphism are not the same thing... Confusing reuse of semantics is different than generalized terminology. One can lead to the other, but careful design (interfaces, interfaces, interfaces) can also prevent it. > Yeah, the next thing to unify will have to be the form > handling. XMLForm and JXForm will be shortly unified. > Hopefully, Woody will be as well. > > Balkanization is the problem. FS is the signal. Community > fragementation is the danger, expecially when blocks will be there. > > So, instead of routing around consensus, let's work toward it, that > means: no abstraction for core parts. I think we've already got lots of it, perhaps everyone is just so used to working with it that mostly we see it as concrete...
