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="com.company.app.AppController"/>
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 "JavaInterpreter".
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.
