[jira] [Resolved] (CALCITE-3328) Immutable beans, powered by reflection

["Julian Hyde (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CALCITE-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julian Hyde resolved CALCITE-3328.
----------------------------------
    Fix Version/s: 1.22.0
       Resolution: Fixed

Fixed in [e88809e7|https://github.com/apache/calcite/commit/e88809e7288db9b7d33be8a67840e02a71327675].

This implementation uses reflection, as I described above. If others want to keep the same API but switch to using code generation (which I expect to be faster, but also make the build process more complicated) I won't object.

> Immutable beans, powered by reflection
> --------------------------------------
>
>                 Key: CALCITE-3328
>                 URL: https://issues.apache.org/jira/browse/CALCITE-3328
>             Project: Calcite
>          Issue Type: Bug
>            Reporter: Julian Hyde
>            Assignee: Julian Hyde
>            Priority: Major
>             Fix For: 1.22.0
>
>
> In quite a few places we have immutable config classes, and because they are immutable we have builders. It all gets quite verbose.
> I propose to add a utility class, {{ImmutableBeans}}, that is able to generate an implementation of a given interface. For example,
> {code:java}
> interface MyBean {
>   @Property  int getAge();
>   MyBean withAge(int age);
>   @Property String getName();
>   MyBean withName(String name);
> }
> MyBean b = ImmutableBeans.create(MyBean.class);
> assertThat(b.withAge(37).withName("Fred").getAge(), is(37));
> {code}
> We could replace {{SqlParser.ConfigBuilder}}, {{Frameworks.ConfigBuilder}}, {{RelBuilder.ConfigBuilder}}, quite a few of the associated {{Config}} classes, and perhaps quite a few fluent classes that we use in tests.
> Work in progress: https://github.com/julianhyde/calcite/tree/3328-immutable-beans



--
This message was sent by Atlassian Jira
(v8.3.4#803005)