[
https://issues.apache.org/jira/browse/CALCITE-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov updated CALCITE-2458:
---------------------------------------
Description:
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) 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).
was:
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) 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).
> 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) 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)
