jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@day.com>
Subject Re: checkins to jcr-server
Date Fri, 09 Dec 2005 17:10:42 GMT
hi brian

thanks for your explanation.

Brian Moseley wrote:

> <http://svn.osafoundation.org/server/cosmo/branches/0.2/src/main/java/org/osaf/cosmo/dav/impl/CosmoDavResourceImpl.java>


> however, i also have to override initProperties in order to initialize 
> the resource's caldav properties. this is an example of a jcr-server 
> method that wasn't designed with subclassing in mind.

the initProperties is indeed a case where i could see a benefit of
the protected access modifier and you may noticed, that i left it 
protected :).

> the fact is, DavResourceImpl is almost perfectly usable for me (it was 
> less so in the past, but it's much better now after the latest 
> refactoring).

glad to hear

> if we keep 
> extensibility as a primary goal for the simple server, then i'll be able 
> to reuse your fine work instead of having to copy it and tweaking little 
> bits here and there.

don't get me wrong, i'm not against extensibility and
i'm happy if you implementation is useful for you
project.

but it feels awkward to me, if all private methods of a
implementation need to be protected... i could never
express things like jukka did, but i agreed.

there are a few non-interface methods that are protected,
because they cover things that are really implementation
specific (nothing to do with Dav-Library in general), but
on the other ask for being used by subclasses:

- getExportContext
- getImportContext
- getNode

on the other hand there is are a couple of methods, that
are just there for improving code readability ('getDavName'),
others that i think contain really internal stuff such
as 'isLocked', 'isFilteredItem' or 'isJsrLockable'.

sometimes i even tend to make private methods for code
that i don't feel totally happy with. i want to encapsulate
it into a separate method to be able to look at this
problem separately. quite often i find those method containing
bugs and sometimes they need to be replaced, if i finally
found a solution that seems better to me. the 'isLocked'
is such a candidate.

this is the point about private methods from my point of
view. since it's an opensource project, i will
not know (and i should not know) about subclasses. but
i must pay attention and respect potential subclasses,
if a mark a method protected.

for methods i can't give this guarantee (for the reasons
mentioned above), i think it would not be ok.

just one more example: the 'setIsCollection' method in the 
DavResourceImpl. this one is a hack from my point of view.
since i wanted to complete my modifications i left it...
but i don't like it a all and i would not want this to
be protected.

hope you understand, what i'm trying to say.
kind regards
angela


Mime
View raw message