Item 1: +1
Item 2: +0 because I cannot agree with interfaces for the sake of interfaces. (You write
"whenever possible": I would prefer "whenever needed").
May be I am an "oldtimer" but I see more benefits to good subclassing
architecture than interfaces+implementations.
Interfaces are a "contractual" tool (as I understand what Jane
explained) by which we engage to not change without very strong reason (and to provide
upgrade paths!)
Reason why I approve the idea of separating what is within (you
modify at your own risk, no tears afterward) and what is exposed outside
(upgrade paths promised...)
Except if interfaces for "inside" classes are needed for
implementation reason, I do not see why we would bother to create them.
Item 3: +1 Designing exposed interfaces would allow to clarify JspWiki
architecture and make it always more flexible for integration...
To package them separately makes clear they are "exposed" for a
longer term...
Subdirectories by "integration mode" are also welcome (plugins for
instance).
Good evening!
Christophe
Andrew Jaquith a écrit :
Most of you have probably been following the debate on package
renaming, and the associated creation of a separate .api package --
with bated breath I'm sure. It's time to get a consensus from the
group about the direction to proceed.
I ask the group for three votes:
ITEM 1.
Immediate renaming of all packages from com.ecyrd.jspwiki to
org.apache.jspwiki, so that we can move to release an early alpha
Apache build.
Details: This would cause all packages currently named
com.ecyrd.jspwiki to be renamed to org.apache.jspwiki
Recommendation: I vote +1 for this item, and recommend the same to the group.
ITEM 2.
Refactoring concrete classes (e.g., WikiEngine) into interfaces
whenever possible, and supplementing them with factory interfaces if
warranted (e.g., interface WikiEngineFactory).
Details: For those of you who use Eclipse, this is similar to an
"Extract interface" refactoring step, where concrete classes like
WikiEngine are turned into interfaces that are meant to be stable. The
concrete class WikiEngine would be renamed to something like
DefaultWikiEngine.
Recommendation: I vote +1 for this item, and recommend the same to the group.
ITEM 3.
Creation of the .api package/package tree, and creation of various
types in this package/package tree (e.g., WikiEngine, WikiPage) for
stable interfaces.
Details: The org.apache.jspwiki.api package has been proposed by Janne
(and partially implemented) as a dedicated package tree where stable
interfaces would live, separate from the existing com.ecyrd.jspwiki
and future org.apache.jspwiki package trees. See the debate at
https://issues.apache.org/jira/browse/JSPWIKI-38 for details. This is
essentially a retroactive vote: majority approval would commit us to
this direction; majority disapproval would cause contents of the .api
package to be reincorporated into the existing tree.
Recommendation: I vote -1 (veto) for this item. I prefer the status
quo, to keep stable interfaces in the existing package tree.
Summary of my votes here:
Item 1: +1
Item 2: +1
Item 3: -1
