[
https://issues.apache.org/jira/browse/CALCITE-3956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17092516#comment-17092516
]
Julian Hyde commented on CALCITE-3956:
--------------------------------------
Again, no. The first sentence of
[https://docs.oracle.com/javase/8/docs/api/java/lang/Comparable.html] says
‘This interface imposes a total ordering on the objects of each class that
implements it.’
You can’t impose a total order on a partial order. For example, if you have a
list of RelOptCost and you try to sort them the sort algorithm will be confused
by the return values from compareTo and (conceivably) might not terminate.
There are problems with RelOptCost, but shoehorning them into Comparable
doesn’t solve them - it pretends they don’t exist, and that is a sure recipe
for further pain in future.
> Unify comparison logic for RelOptCost
> -------------------------------------
>
> Key: CALCITE-3956
> URL: https://issues.apache.org/jira/browse/CALCITE-3956
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Liya Fan
> Assignee: Liya Fan
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, comparisons between RelOptCost objects are based on 3 methods:
> 1. {{boolean isLe(RelOptCost cost)}}
> 2. {{boolean isLt(RelOptCost cost)}}
> 3. {{boolean equals(RelOptCost cost)}}
> The 3 methods used in combination determine the relation between RelOptCost
> objects.
> There are some problems with this implementation:
> 1. Some logic is duplicate in the above methods, making it difficult to
> maintain.
> 2. To determine the relation between RelOptCost objects, we often need to
> call more than one comparison methods, leading to performance overhead.
> 3. Since the logic is spread in multiple methods, it is easy to end up with
> contradictive comparison logic, which will suprise the users. For example,
> the following assertion should hold according to common sense:
> {{if a >=b, then we have a > b or a == b}}
> However, with the current implementation of {{VolcanoCost}}, we can easily
> create instances that violate the above assertion.
> To solve the problems, we want to make {{RelOptCost}} extends the
> {{Comparable<RelOptCost>}}, so the comparison logic is unified in the
> {{compareTo}} method, which solves the above problems.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
