[
https://issues.apache.org/jira/browse/CALCITE-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573876#comment-16573876
]
Vladimir Sitnikov edited comment on CALCITE-2458 at 8/8/18 9:04 PM:
--------------------------------------------------------------------
{quote}If we were to use Kotlin for tests, what would be the additional steps
to set up a Calcite build environment?
{quote}
I think it boils down to configuring {{kotlin-maven-plugin}} + adding
{{<artifactId>kotlin-stdlib</artifactId>}} dependency or something behind those
lines.
I think we should just try adding the plugin, add a test, and see how it
breaks. I just wanted to get opinions before hacking pom files.
Configuring "style check" is another issue, but it should still be solvable by
Maven.
{quote}How would it affect Calcite's compatibility with other projects (say
projects that do not use Kotlin, or use a different version of Kotlin)? Could
we continue to use maven as the (only) build tool?
{quote}
I'm not sure re Calcite, yet Kotlin works with Maven just fine. I hope test
Kotlin does not spoil to the production dependencies (why should they?), so
other projects would not even know we use Kotlin.
Re the language and kotlin-stdlib, JetBrains claims strong backward
compatibility, so even if we happen to use Kotlin for regular code, it should
be not worse than Guava.
was (Author: vladimirsitnikov):
{quote}If we were to use Kotlin for tests, what would be the additional steps
to set up a Calcite build environment?
{quote}
I think it boils down to configuring {{kotlin-maven-plugin}} + adding
{{<artifactId>kotlin-stdlib</artifactId>}} dependency or something behind those
lines.
I think we should just try adding the plugin, add a test, and see how it
breaks. I just wanted to get opinions before hacking pom files.
Configuring "style check" is another issue, but it should still be solvable by
Maven.
{quote}How would it affect Calcite's compatibility with other projects (say
projects that do not use Kotlin, or use a different version of Kotlin)? Could
we continue to use maven as the (only) build tool?
{quote}
I'm not sure re Calcite, yet Kotlin works with Maven just fine. I hope test
Kotlin does not spoil to the production dependencies, so other projects would
not even know we use that.
Re the language and kotlin-stdlib, Jetbrains claims strong backward
compatibility, so even if we happen to use Kotlin for regular code, it should
be not worse than Guava.
> Evaluate use of Kotlin for unit tests
> -------------------------------------
>
> Key: CALCITE-2458
> URL: https://issues.apache.org/jira/browse/CALCITE-2458
> Project: Calcite
> Issue Type: Improvement
> Affects Versions: 1.17.0
> Reporter: Vladimir Sitnikov
> Assignee: Julian Hyde
> Priority: Major
>
> It looks like Kotlin might simplify writing tests:
> 1) Calcite tests often create expressions (linq4j, rex, sql, etc), and the
> order of elements is "backwards".
> For instance, "x AND (y OR z)" becomes {{and(x, or(y, z))}} at best. Writing
> and updating such code is a bit tedious. It seems like {{AND}} and {{OR}}
> could be infix functions (see
> [https://kotlinlang.org/docs/reference/functions.html#infix-notation|https://kotlinlang.org/docs/reference/functions.html#infix-notation]
> )
> 2) [extension
> functions|https://kotlinlang.org/docs/reference/extensions.html#extensions]
> Calcite tests often tend to create DSLs for testing (e.g. CalciteAssert,
> Tester, and so on). The idea there is to enable fluent APIs and somehow tame
> the complexity. The problem there is Java is not that suitable for building
> DSLs.
> Extension methods in Kotlin allow to "add a method to existing class", and it
> might be helpful for cases like
> {{parser.parse("...").assertConvertsTo("...")}} where {{assertConvertsTo}} is
> an extension method (in Java it could be a static method in CalciteAssert
> class)
> 3) [data classes|https://kotlinlang.org/docs/reference/data-classes.html].
> Apparently, Calcite deals with data, and data classes could help here as well.
> 4) [default
> parameters|https://kotlinlang.org/docs/reference/functions.html#default-arguments]
> 5) [multiline string
> literals|https://kotlinlang.org/docs/reference/basic-types.html#string-literals]
> I think it would be much better to co-locate SqlToRel test code and its
> expected results, so one can see the test code and expectations.
> 6) Re Checkstyle: there's a standard code style for Kotlin (and it can be
> verified automatically), however I am not sure we could configure it in the
> way we have Checkstyle rules. Calcite uses parenthesis a lot, and I am not
> sure how Kotlin would deal with it.
> It looks like adding Kotlin as a {{<scope>test</scope>}} should not be a
> problem, so I wonder if that is feasible.
> PS. Using Kotlin for regular Calcite code is a different story, and I am not
> sure I want to open that discussion (well, I would love to, yet it might be a
> major change with ripples here and there). I just think it should be safer to
> try writing some TEST code for Calcite in Kotlin, then evaluate it for other
> cases (if necessary at all).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
