[
https://issues.apache.org/jira/browse/CALCITE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418894#comment-17418894
]
Jacques Nadeau commented on CALCITE-4787:
-----------------------------------------
I've updated my patch to support the combination behavior. Things look
reasonable. One thing I had to accomodate is that the base Config interface
with* methods are not parameterized. Since as part of this we want to avoid
downcasting, I introduce a sub interface called TypedConfig<T> which extends
Config but uses a parameter to ensure that the with* methods return their
correct types. This must be done outside the existing uses of EMPTY to avoid
disruption to existing users. If the change is applied directly to the Config
interface, existing users operations would no longer work.
If a user working outside of Calcite wants to subclass a config using the new
pattern, they will need to either declare an interface override for the desired
methods (so they return the correct subclass) or use unwrap() to downcast. An
example of how this works with unwrap can be seen
[here|https://github.com/apache/calcite/blob/80e2656fcb89cb1a1a5fdfb3e5a9e350cb415109/core/src/main/java/org/apache/calcite/rel/rules/AggregateProjectStarTableRule.java#L80].
In this example, AggregateStarTableRule.Config is a concrete configuration and
thus using withOperandSupplier returns AggregateStarTableRule.Config. An
implementor could have alternatively added `ConfigÂ
withOperandSupplier(OperandTransformer)` to the subclass definition and avoided
unwrap(). Both seem fine and are only related to situations where users are
implementing subclasses of existing configs.
> Evaluate use of Immutables instead of ImmutableBeans
> ----------------------------------------------------
>
> Key: CALCITE-4787
> URL: https://issues.apache.org/jira/browse/CALCITE-4787
> Project: Calcite
> Issue Type: Improvement
> Reporter: Jacques Nadeau
> Assignee: Jacques Nadeau
> Priority: Major
> Labels: pull-request-available
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> In the creation of CALCITE-3328, [Immutables|https://immutables.github.io/]
> was discussed as an alternative to a custom implementation. This ticket is to
> evaluate the impact to the codebase of changing. Ideally, introduction of
> immutables would both add flexibility and reduce the amount of code
> associated with these classes.
> Immutables works via annotation processor which means that it is should be
> relatively seamless to build systems and IDEs.
> The switch would also make it easier to work with these objects types in the
> context of aot compilation tools like GraalVM.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
