Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <439898F5.5070301@zitting.name>
Date: Thu, 08 Dec 2005 22:35:01 +0200
From: Jukka Zitting <jukka@zitting.name>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: jackrabbit-dev@incubator.apache.org
Subject: Re: checkins to jcr-server
References: <4397F383.1090209@day.com> <439859E5.8050100@osafoundation.org>
In-Reply-To: <439859E5.8050100@osafoundation.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Brian Moseley wrote:
> i think the burden of proof should be on the person who wants to keep 
> methods private ;)

I'm not so familiar with the jcr-server design that I can comment on 
design decisions there, but in general i disagree with the above 
principle. :-)

A method should be private if there is no specific reason otherwise. A 
non-private method is a part of the external API contract of a class and 
  carries with it all the burden of API compatibility. The narrower the 
API contract of a class is the easier the class is to restructure to 
match an evolving environment. A narrower API is also easier to document 
and maintain. In general it is much easier to relax the visibility of a 
method when needed than to restrict the availability of a non-private 
method.

BR,

Jukka Zitting