[
https://issues.apache.org/jira/browse/CALCITE-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587993#comment-16587993
]
Vladimir Sitnikov commented on CALCITE-2458:
--------------------------------------------
maven-dependency-plugin fails to recognize some of Kotlin dependencies:
{noformat}[WARNING] Unused declared dependencies found:
[WARNING] org.jetbrains.kotlin:kotlin-test-junit:jar:1.2.60:test{noformat}
Commits like
https://github.com/apache/calcite/pull/786/commits/876d94f0a935dc7214c1c906947efbcd66426ae8
can silence it.
On the other hand, here's how Kotlin test failure look like:
https://travis-ci.org/apache/calcite/jobs/418880873#L3266-L3269
Is there anything to do before https://github.com/apache/calcite/pull/786 can
be merged?
> 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)
