[
https://issues.apache.org/jira/browse/CALCITE-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16704020#comment-16704020
]
Julian Hyde commented on CALCITE-2632:
--------------------------------------
I'm reviewing and testing this, and reworking a little:
* Use {{Objects.equals(x, y)}} in preference to {{x.equals\(y)}} only when x or
y may be null;
* Use {{x == y}} when objects are primitive or enums;
* Add {{@Nonnull}} annotations to methods such as {{toString}}, and drop
over-defensive coding;
* When overriding {{Object.equals}}, use the following pattern whenever possible
{code}
return this == obj
|| obj instanceof Type
&& a1.equals(obj.a1) ...
{code}
> Add hashCode and equals implementations to RexNode
> ---------------------------------------------------
>
> Key: CALCITE-2632
> URL: https://issues.apache.org/jira/browse/CALCITE-2632
> Project: Calcite
> Issue Type: Bug
> Reporter: Zoltan Haindrich
> Assignee: Zoltan Haindrich
> Priority: Major
> Fix For: 1.18.0
>
>
> Right now RexNode doesn't have any equals or hashCode functions; which makes
> it rely on the default implementation.
> But when we are writing simplification logics we sometimes forget to use
> {{toString()}} during comparisions and may try to rely on pure equals:
> * there is a [Set of
> RexNode-s|https://github.com/apache/calcite/blob/5b16e23dff03e5eaed80642ae91e28ebf806e6b0/core/src/main/java/org/apache/calcite/rex/RexSimplify.java#L1104]
> during {{AND}} simplification and in [RexUtil as
> well|https://github.com/apache/calcite/blob/5b16e23dff03e5eaed80642ae91e28ebf806e6b0/core/src/main/java/org/apache/calcite/rex/RexUtil.java#L321]
> * I've by mistake just written rexNode.equals(otherRexNode) during the
> implementation of CALCITE-1413
> * I've just bumped into the same thing...that
> [RexUtil.andNot|https://github.com/apache/calcite/blob/5b16e23dff03e5eaed80642ae91e28ebf806e6b0/core/src/main/java/org/apache/calcite/rex/RexUtil.java#L1888]
> is also rely on it....and I think those comparisions go back a while
> (~3years at least) ; and a bug is not appeared from it because this
> comparision is in most cases false.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)