I also had a separate module in mind when I made the comment during the meetup.
Although, I don't want to force people to rewrite their code in another language in order to be accepted, the truth is that using Java 8 will be the easiest way to get this in. I think we are using Java 8 in the biggest part of the project so it might be better to stick to it for the moment. If we want to jump to a bigger version I guess this will be a discussion concerning the entire project. Java remains more popular compared to Kotlin so it will be also easier to find reviewers to get this in and maintain it in the near future. Best, Stamatis On Fri, Jan 21, 2022 at 1:43 AM Gavin Ray <[email protected]> wrote: > Got it, and about the standalone module, yeah absolutely. That makes a lot > of sense. > In that case, it would be an additional dependency you'd add, like > "calcite-csv" and could live alone as a sub-project right? > > I will take inspiration from the way that the "piglet" adapter is written > and try to follow those general conventions, thank you! > > On Thu, Jan 20, 2022 at 7:03 PM Julian Hyde <[email protected]> > wrote: > > > There is one other front-end language (besides SQL) in Calcite: the > > ‘piglet' module implements Pig Latin (which is the language spoken by > > Apache Pig). I think the other languages, such as GraphQL, should each be > > their own module. > > > > Calcite has many adapters (i.e. back-ends), and one-module-per-adapter > has > > been working well. > > > > I’m not going to express an opinion about Kotlin vs Java 17 vs Java 8. > > > > > > > On Jan 20, 2022, at 12:25 PM, Gavin Ray <[email protected]> wrote: > > > > > > Stamatis made a remark during the meetup about integrating the GraphQL > > > library as a module in core. > > > Something like GqlToRelConverter, similar to SqlToRelConverter. > > > > > > I hadn't thought of this, it's a brilliant idea. > > > I would like to shift my development into practices that could > eventually > > > be accepted upstream. > > > > > > Is it correct to assume that this means I'll need to swap Kotlin for > > Java? > > > Are there any organizational best-practices, conventions or other > things > > to > > > keep in mind? > > > > > > If I must use Java, can I use JDK17 to take advantage of things like > > > records, sealed types and "switch" pattern matching? > > > > > > Thank you =) > > > > >
