[
https://issues.apache.org/jira/browse/CALCITE-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16756429#comment-16756429
]
Julian Hyde commented on CALCITE-1166:
--------------------------------------
I didn't consider it. The current system kind of evolved, while keeping
backwards compatibility. There wasn't much pain, because operands don't have
very many arguments.
Remember that we need to build trees of operands, and fluent builders are not
too good at building trees. (RelBuilder builds trees, but it linearizes them by
using an internal stack, and so the resulting code doesn't have the tree
structure.)
> 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)