lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrien Grand <jpou...@gmail.com>
Subject Re: Weird cloning in QueryNode implementations
Date Tue, 11 Apr 2017 06:41:57 GMT
I think you are right that those field copies are not necessary.

Le mar. 11 avr. 2017 à 06:06, Trejkaz <trejkaz@trypticon.org> a écrit :

> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message