calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Sitnikov (JIRA)" <>
Subject [jira] [Created] (CALCITE-2458) Evaluate use of Kotlin for unit tests
Date Wed, 08 Aug 2018 16:38:00 GMT
Vladimir Sitnikov created CALCITE-2458:

             Summary: Evaluate use of Kotlin for unit tests
                 Key: CALCITE-2458
             Project: Calcite
          Issue Type: Improvement
    Affects Versions: 1.17.0
            Reporter: Vladimir Sitnikov
            Assignee: Julian Hyde

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

2)  [extension functions|]
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|]. Apparently, Calcite
deals with data, and data classes could help here as well.

4) [default parameters|]

5) 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.

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 wring some TEST code for Calcite in Kotlin,
then evaluate it for other cases (if necessary at all).

This message was sent by Atlassian JIRA

View raw message