Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
MIME-Version: 1.0
From: Trejkaz <trejkaz@trypticon.org>
Date: Tue, 11 Apr 2017 14:06:18 +1000
Message-ID: <CADuAvze+eshNsP4+5QS84gaYn=qSeN+fnCPz-8-YszK9M=5apA@mail.gmail.com>
Subject: Weird cloning in QueryNode implementations
To: Lucene Users Mailing List <java-user@lucene.apache.org>
Content-Type: text/plain; charset=UTF-8
archived-at: Tue, 11 Apr 2017 04:06:26 -0000

Hi all.

Something queer I found while looking at QueryNode implementations is
this sort of thing:

    @Override
    public FieldQueryNode cloneTree() throws CloneNotSupportedException {
        FieldQueryNode fqn = (FieldQueryNode) super.cloneTree();
        fqn.begin = this.begin;
        fqn.end = this.end;
        fqn.field = this.field;
        fqn.text = this.text;
        fqn.positionIncrement = this.positionIncrement;

        return fqn;
    }

I guess what I don't get is the point of all these field copies, because:

    * super.cloneTree() seems to call QueryNodeImpl#cloneTree()
    * QueryNodeImpl#cloneTree seems to call Object#clone()
    * Object#clone() seems to already copy all primitives and
references (a "shallow copy")

So to me it looks like the query node classes are doing a lot of
pedalling, but that the gears aren't really connected to the wheels,
and that classes should only override these if they have a more
complex object which isn't already taken care of automatically.

Or am I missing something?

TX

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org