[
https://issues.apache.org/jira/browse/CALCITE-7224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18029906#comment-18029906
]
Zhen Chen commented on CALCITE-7224:
------------------------------------
Hi [~mbudiu], perhaps we need to discuss how to approach the refactoring in
this JIRA ticket. However, I have one question: you mentioned using the visitor
pattern to handle function idempotency or other properties. But currently, many
functions are implemented as SqlBasicFunction without their own specific
classes—they only differ by their SqlKind. How can we use the visitor pattern
to handle them in this case?
> Refactor function property system to use a unified flag field
> -------------------------------------------------------------
>
> Key: CALCITE-7224
> URL: https://issues.apache.org/jira/browse/CALCITE-7224
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.40.0
> Reporter: Zhen Chen
> Priority: Minor
>
> Currently, SqlOperator and its related classes use individual boolean fields
> (e.g., isDeterministic, isDynamic, maybe isIdempotent) to represent various
> function properties. This approach has several drawbacks as the number of
> properties grows:
> * Maintenance Overhead: Adding a new property requires adding a new
> method and field across multiple classes.
> * API Bloat: The interface becomes cluttered with numerous getter methods.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
