Update: in my case, the easiest way to unblock the situation was following
suggestion #2 from Jacques ("Write a concrete class that implements the
declared interface").On Fri, Dec 3, 2021 at 8:58 AM Ruben Q L <rube...@gmail.com> wrote: > Hello, > > Julian, I find myself in a similar position. I upgraded into Calcite 1.28 > in a certain project. This project had several custom rules, which (due to > the rule config refactoring [1], [2], [3]) now use some deprecated elements > (e.g. RelRule#Config#EMPTY). Recently I tried to adapt my rules to get rid > of the deprecated elements and I stumbled upon the same problem that you > mention. The situation will be more serious in 1.29, when these deprecated > elements are completely removed. > Jacques, thanks for the feedback. I will also take a look at your > proposals. > > Regards, > Ruben > > [1] https://issues.apache.org/jira/browse/CALCITE-4787 > [2] https://issues.apache.org/jira/browse/CALCITE-4825 > [3] https://issues.apache.org/jira/browse/CALCITE-4830 > > > On Thu, Dec 2, 2021 at 11:24 PM Julian Hyde <jhyde.apa...@gmail.com> > wrote: > >> Thanks for the prompt reply, Jacques. I’ll explore your suggestions and >> let you know what I find. >> >> > On Dec 2, 2021, at 1:33 PM, Jacques Nadeau <jacq...@apache.org> wrote: >> > >> > Hey Julian, >> > >> > To me, there are currently three avenues I envisioned for extension >> project >> > use: >> > 1. Use the Immutable project or similar alternatives (e.g. [1]) >> > 2. Write a concrete class that implements the declared interface. >> > 3. Use a record metaphor appropriate to the environment you're in that >> > implements the interface (Record in java 14+, Data class in Kotlin, etc) >> > >> > There is a fourth option, which is extending Immutable generated >> > code. Because Immutables was new in 1.28, I wanted to avoid introducing >> new >> > surface area directly related to the Immutables compiler/compiled class >> and >> > thus made all the implementations package private [1]. I felt this was >> > safer than introducing these directly but if we feel like that is >> something >> > we should expose, it would be a relatively straightforward change. Note >> > that the current pattern is only producing code for concrete subclasses >> of >> > RelRule.Config for specific rules, not the generic RelRule.Config which >> is >> > only an abstract interface. >> > >> > Given your constraints, I would explore #2 or #3 (and would love to hear >> > feedback on #4). >> > >> > One other question that comes to mind is that is this a pain more in >> > specifically the concept of new direct subclasses of RelRule.Config or >> > subclasses of other concrete rule config subclasses. >> > >> > [1] https://github.com/Randgalt/record-builder >> > [2] >> > >> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/CalciteImmutable.java#L30 >> > >> > On Thu, Dec 2, 2021 at 12:20 PM Julian Hyde <jhyde.apa...@gmail.com> >> wrote: >> > >> >> I’m trying to write a planner rule in a dependent project. (What what >> it’s >> >> worth, the project is not open source, and is implemented in Kotlin.) I >> >> don’t want to make the dependent project depend on the Immutables >> library, >> >> because that introduces an annotation processor and might destabilize >> our >> >> build. >> >> >> >> I need to implement RelRule.Config in order to override the toRule >> method >> >> to create an instance of my rule. But as RelRule.Config uses >> Immutables, it >> >> does not have an implementation that I can subclass. >> >> >> >> Has anyone else run into this problem? >> >> >> >> Julian >> >> >> >> >> >>
