[jira] [Commented] (CALCITE-1166) Disallow sub-classes of RelOptRuleOperand

["Vladimir Sitnikov (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CALCITE-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16759353#comment-16759353 ] 

Vladimir Sitnikov commented on CALCITE-1166:
--------------------------------------------

{quote} Remember that we need to build trees of operands, and fluent builders are not too good at building trees{quote}
That is true, however it is a bit sad to pick a proper operand or operandJ method since every time there are too much unrelated arguments.
Trait argument is not always needed for the rule however operandJ requires it.
On top of that, {{some}} vs {{any}} is another culprit. It can't write that from scratch, and I have to see other rules and/or some/any source code.


I just thought builders there would simplify creating operands. At the same time I don't like the idea of multiplying the number of operand/operandJ methods.

I do not suggest use stack-based approach. I guess something like {{OperandBuilder#input(OperandBuilder<V> children);}}, {{OperandBuilder#inputs(OperandBuilder... children);}} would work.

The use site would look like a tree:

{code:java}operand(Join.class)
        .satisfies(x -> x.getInputs().size()==1)
        .inputs(
                operand(Filter.class).has(Convention.NONE),
                operand(Project.class).satisfies(x -> 42 > 0))
        .build();{code}

> Disallow sub-classes of RelOptRuleOperand
> -----------------------------------------
>
>                 Key: CALCITE-1166
>                 URL: https://issues.apache.org/jira/browse/CALCITE-1166
>             Project: Calcite
>          Issue Type: Bug
>            Reporter: Julian Hyde
>            Assignee: Julian Hyde
>            Priority: Major
>             Fix For: 1.8.0
>
>
> Disallow sub-classes of {{RelOptRuleOperand}}. The only reason that people have sub-classed {{RelOptRuleOperand}} is to override the {{boolean matches(RelNode)}} method, and you can now achieve that by supplying a {{Predicate}} to the constructor.
> Next release, we will deprecate {{RelOptRuleOperand}}'s protected constructor and create a new private or package-protected one. Later we will remove that constructor.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)