[
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)
