9 Mar
2009
9 Mar
'09
1:58 p.m.
Vincent Massol wrote:
On Mar 9, 2009, at 12:26 PM, Dan Miron wrote:
Vincent, I don't understand what's the problem with keeping the package
name as it is now? There's nothing that prevents users (API users) to
instantiate classes in the internal package. The only thing that changes
is the import statement, the same constructor can be used. And with
modern development tools the package is transparent.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Sergiu Dumitriu wrote:
The only possibility to keep our "component" implementation classes
non user-public is to add user-public factory classes.
ParserFactory parserFactory = new DefaultParserFactory();
Parser parser = parserFactory.createParser(new
XWikiSyntax(SyntaxType.XWIKI, "2.0"));
parser.parse(new StringReader("**whatever**");
...
instead of:
Parser parser = new WikiModelXWikiParser(...);
parser.parse(new StringReader("**whatever**");
...
Note that these factory classes will need to have user-public
implementations of course so this is swapping one problem for another
(albeit smaller). Also, it means that we have an extra class that is
useless when using components.
Now while this works quite well for parsers since there are different
implementations for them, it's going to be a real pita for most other
components which have only a default implementation. For example, I
don't see us writing:
TransformationManagerFactory transformationManagerFactory = new
DefaultTransformationManagerFactory();
TransformationManager transformationManager =
transformationManagerFactory.createTransformationManager();
transformationManager.performTransformations(...);
instead of:
TransformationManager transformationManager = new
DefaultTransformationManager();
transformationManager.performTransformations(...);
Now the first one to suggest using singleton pattern and statics gets
a blame... :)
WDYT? Vincent Massol wrote:
I agree to Sergiu. Keeping the implementation and the specifications
separately provides more accuracy to our api. Hi,
Some time ago we agreed that component implementations should be
located in the internal package. I now believe it's wrong if we want
to allow users to use our modules separately from the rest of
XWiki as
standard java beans. I think it's a good property to have that users
can integrate our modules into their own code without taking the
whole
of XWiki. This is what I'm trying to do with the rendering module.
Thus I'm proposing to move the components out of the internal module
*only* for the rendering module for now even though I suspect that
we'll want to do that for all modules eventually.
Here's my +1
What's the advantage? Or, what's wrong with keeping the internal
package? Apart from a longer package name, there's no bound
semantics on
such a package. IMO it even has the advantage that it clearly
delimits
interfaces and abstract base classes from implementations.