cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <>
Subject Re: [RT] Generalizing the flow
Date Sat, 05 Jul 2003 21:18:05 GMT
Sylvain Wallez wrote:

> Christopher Oliver wrote:
>> Sylvain Wallez wrote:
>> <snip>
>>> Names are one of the most important things in design, since it's 
>>> first through the names that a user goes into a set of classes. Bad 
>>> names imply wrong understanding. Abstractions named after a 
>>> particular implementation make other implementations look clumsy, 
>>> since they don't fit into the name, even if they fit into the real 
>>> underlying concept.
>> Fine. Would you mind demonstrating at least one alternative 
>> implementation of "FlowEngine" and "FlowController"  so that the rest 
>> of us can make a technical assessement of how well it "fits" if you 
>> intend to make these name changes? 
> Let's simply consider the second implementation we have today : Alex 
> Krut's ATCT implementation [1]. Interestingly, it is 
> continuation-based, and so technically similar to the JavaScript 
> implementation :
> - the interpreter is not an interpreter : it runs compiled Java. 
> Wouldn't "ATCTFlowEngine" have been better than the chosen 
> "JavaIntepreter" ? Clumsy name engendered by a wrong name for the 
> underlying concept.
> - the flow functions aren't functions but classes. Interestingly, 
> these should extend "AbstractController". Alex didn't fell into the 
> trap of naming them "AbstractFunction".
> And this leads to the following clumsy notation : <map:call 
> function=""/>

I don't know, Sylvain. The Sun JVM is also a Java interpreter and so is 
for that matter ATCT itself.  I don't see what's so clumsy about 

Also it looks to me that Alex Krut  is referring to a Java method in 
<map:call function="run"> not a class. "Method" is another name for a 
function, so I really don't see your point.

We could change it to <map:call operation="blah"> if you wan't something 
more programming language agnostic than "function".

> So, even if this is a continuation-driven implementation, we have here 
> the demonstration that current names aren't the right ones...

See above. I don't see a problem with the current names.

View raw message