incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Murray Altheim <>
Subject Re: Vote requested: package renaming
Date Tue, 30 Dec 2008 22:43:35 GMT
I do think the vote was a bit premature, despite the length of the
conversation. It's an important discussion so the length isn't an
issue for me.

Item #1: (withdrawn)

Item #2: +1
If I am to understand "whenever possible" as actually "whenever
necessary and reasonable" then I'm in favour of moving forward
with this. This goes along with Item #3.

Item #3: -1 (see below)

Andrew Jaquith wrote:
> Janne Jalkanen wrote:
>> +1.  I think this is absolutely mandatory, if we want to have stable
>> interfaces.
> I do not agree that it is "absolutely mandatory." Interfaces *should*
> be stable -- that's a tenet of good Java style. If we design
> interfaces carefully (as we both agree we should), why create a whole
> new package tree? It's redundant and inelegant.

This whole discussion doesn't seem to be about the *presence* of
interfaces. We already have a lot of interfaces:

     Acl, AclEntry, AclManager, AdminBean, Authorizer, Command, DavProvider,
     DiffProvider, DynamicAttachmentProvider, FastSearch, FormHandler,
     GenericHTTPHandler, GroupDatabase, HeadingListener, InitializablePlugin,
     InternalModule, PageFilter, ParamHandler, ParserStagePlugin, RPCCallable,
     SearchProvider, SearchResult, Step, StringTransmutator, URLConstructor,
     UserDatabase, UserProfile, VersioningProvider, Watchable, WebAuthorizer,
     WikiAttachmentProvider, WikiEventListener, WikiPageProvider, WikiPlugin,
     WikiProvider, WikiRPCHandler

It seems to be about the presence of a new "api" package. So the big
question is really: which ones of these are "stable", which ones aren't?
Which ones will remain in 3.0, which not? If a new "api" package exists,
which ones move into it? What are the criteria for that move? And isn't
that move itself disruptive?

I understand the desire for a set of stable interfaces, but I still don't
see the "mandatory" justification for their movement into a new package.
Interfaces currently do and certainly could exist in 3.0 in their
respective packages; they don't by any technical requirement *need* to be
a new package. Let's be clear about about that. The argument is on either
side an aesthetic one, not a technical one. It is about clarity and ease
of use and ease of understanding, not a requirement. So please let's stop
making this line-in-the-sand approach to the discussion.


Would we move *all* of the surviving interfaces above into an API package
in 3.0? If not, which ones? Why or why not? What justifies the movement
into the API package? Some notion of stability? Isn't the very movement
from a current location to a new API location going to be a very
disruptive action that breaks code? The idea that an interface evolves
in stability and then is moved into the API package doesn't really make
practical sense. Putting an interface into the API package is a measure
of *intention* not reality, and we know that over time (e.g., over any
given year) we can't really guarantee that stability -- we will have to
make changes as we have to make changes, especially given that we can't
predict the future of the project. We'll find out the limitations and
problems with the APIs only when they are used (e.g., I'm a good guinea
pig for that as I'll be finding issues only as I dig in).

So my vote for Item #3 is -1 (sorry, Janne). I think we should continue
to move forward with the Apache agenda as makes sense with the JCR work,
such that we basically move everything over into the new namespace, but
I can't see that we *need* an API package to accomplish this. That is,
unless we were to move *all* the interfaces into that package, as any
interface is a form of guarantee in good programming practice. If there
are unstable interfaces they should simply be labeled as such (perhaps
with the @deprecated tag), with the tacit assumption that any unlabeled
interface in the code is stable and a guarantee, as it should be.

I think we can accomplish Janne's stated goals without a new package.
There is simplicity for a developer in finding the interface for a
class in the same package as the rest of the related code. I like the
idea of a separate jar file of interfaces, but that can actually exist
with the interfaces in their respective packages; this doesn't need to
be one package.

I don't consider this vote an end to the discussion. I don't feel like
I've heard Janne's justification for the new package as a requirement,
the criteria for which ones get moved, nor what he'd do with each of
the existing interfaces. I'm not asking for an exhaustive list (as I'm
not trying to make this more difficult than need be), but I am
interested in knowing the criteria for making these judgments.


Murray Altheim <murray08 at altheim dot com>                       ===  = =                                     = =  ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk               = =  = =

       Boundless wind and moon - the eye within eyes,
       Inexhaustible heaven and earth - the light beyond light,
       The willow dark, the flower bright - ten thousand houses,
       Knock at any door - there's one who will respond.
                                       -- The Blue Cliff Record

View raw message