ITEM 2.
Refactoring concrete classes (e.g., WikiEngine) into interfaces
whenever possible, and supplementing them with factory interfaces
if warranted (e.g., interface WikiEngineFactory).
CLARIFICATION via discussion: extraction would be done with the
understanding that careful consideration would be given to the
methods extracted, and to the classes refactored.
Murray: +1
Andrew: +1
Harry: +1
Janne: +0.5 (I think: please let me know if I have misinterpreted)
I voted -1 against the proposition as written, because I interpret
calls for votes *literally*.
Note that according to Apache rules, in any code change votes a
binding -1 constitutes a veto. So, this one does not pass.
Conclusion: this vote passes, unless I've got Janne's vote wrong.
I'd recommend we move forward with this carefully, and agree on
changes via group consensus as we go. Janne's comments are well-
taken: blind refactoring is not the goal here.
Craig's point of proper subclassing is a good one and needs to be
taken into account. It might make sense to look whether we can
create good abstract subclasses for certain objects (for example,
WikiPage actually comes to mind as a good candidate for an abstract
base class, since it's mostly an accessor class). WikiContext is
something which probably works well as an interface, but WikiEngine
might also be a good base class.
What I am really aiming is that someone who embeds JSPWiki does not
have to start a WikiEngine to get the benefit of JSPWiki rendering
engine (there is an open issue for this), but simply provide their
own implementations for certain classes (and not low-level ones like
Providers, which is the case right now). This means that we need to
have either sane default implementations or possibly interfaces for
WikiEngine, WikiPage and WikiContext (and redesign some things for
PluginManager and VariableManager).
However, this needs a lot more thinking, and we can't just do it
without proper discussion on this subject.
/Janne
