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="com.company.app.AppController"/>
So, even if this is a continuation-driven implementation, we have here the demonstration that current names aren't the right ones...
Even so, I really don't like your names. <map:call> made perfect sense when calling a continuation or function (since they are actually callable). I don't quite get what "calling" a "state" means.
Does this mean <map:call> is bad also ?
Sylvain
[1] http://www.freeroller.net/page/alexkrut/20030511
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com