Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of anchela@adobe.com designates
 64.18.1.25 as permitted sender)
Message-ID: <500E8A4A.5070403@adobe.com>
Date: Tue, 24 Jul 2012 13:43:06 +0200
From: Angela Schreiber <anchela@adobe.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
 rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: <oak-dev@jackrabbit.apache.org>
Subject: Re: Comment regarding TreeImpl#remove
References: <500E8764.8040109@adobe.com>
In-Reply-To: <500E8764.8040109@adobe.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

just found that Tree#getStatus() never returns REMOVED (see OAK-207).
if that was the reason for that extra check i would suggest to
refactor the code and check for status removed... that felt much
clearer to me.

gruesse
angela

On 7/24/12 1:30 PM, Angela Schreiber wrote:
> hi michael
>
> the implementation of Tree#remove starts with the following line:
>
>           if (!isRoot()&&  parent.hasChild(name)) {
>
> and it seems to me that testing for the parent containing the
> Tree that i am having at hand is superfluous. is that the
> leftover of a refactoring or could it really occur that in this
> situation parent.hasChild returns false? if the latter was
> true, i think this line deserves a little comment explaining
> to the poor reader what are the circumstances of that behaviour.
> maybe we would even need some log output for that special case.
>
> what do you think?
> angela