[jira] [Comment Edited] (CALCITE-2458) Evaluate use of Kotlin for unit tests

["Vladimir Sitnikov (JIRA)" <ji...@apache.org>]

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