Undeniably multi-line strings can improve the readability of the code and
facilitate reviews but I would prefer if we didn't refactor existing tests
from Java to Kotlin mainly for two reasons:
1. Losing the history is an important disadvantage for me. Quite often, I
find my self looking in the
I don't see a major benefit to switching to an entirely new language to get
multiline strings. I agree that sticking to Java makes sense.
Kevin Risden
On Mon, Dec 16, 2019 at 12:50 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> Feng>Introducing another language
>
> It is the same
Feng>Introducing another language
It is the same language that is used for the build scripts, so it is not a
new language.
Danny> in the code evolving and the Scala has many
Danny> tricky problems especially the version compatibility
Kotlin has strong backward compatibility.
" It is pretty good as a pure Java project"
+1 for Danny's comment.
Introducing another language (without strong demands) brings burden for
project maintenance and evolution.
Best,
Feng
Danny Chan 于2019年12月16日周一 上午11:34写道：
> I also have the same concern with Julian, in Apache Flink SQL, we did
I also have the same concern with Julian, in Apache Flink SQL, we did a lot of
code with Scala, but in the code evolving and the Scala has many tricky
problems especially the version compatibility. So finally, we decide to move on
to Java code: rewrite exiting Scala code to Java again.
I don’t
Before coming to Calcite, I works quite some time on Scala. The code style
shares some similarities with Kotlin -- It's much simple and easier to read
when you write a test.
But we should think twice whether to bring in another language.
To answer Haisheng's question:
Because default lex config is
I agree with Julian.
Changing to Kotlin needs lots of error, but gets a little gain. Besides, It
costs much more
time to write a test if developers are not familiar with Kotlin. I
prefer to use Java as it is now.
Best,
Chunwei
On Mon, Dec 16, 2019 at 9:02 AM Julian Hyde wrote:
> I don't
I don't think we should do this.
Multi-line strings are a bit unwieldy, but they're not a major
problem. Transitioning our tests to a different language (Kotlin) is a
drastic solution. It requires developers to understand a new language,
and it loses all history from the source files.
Julian
On
I've filed two PRs to evaluate the impact of the replacement.
$ to _: https://github.com/apache/calcite/pull/1659
203.3sec, 5510 completed, 3 failed, 91 skipped, Gradle Test Run
:core:test
$ to #: https://github.com/apache/calcite/pull/1660
196.7sec, 5510 completed, 53 failed, 91 skipped,
kov
> 日 期：2019年12月15日 06:09:37
> 收件人：Apache Calcite dev list
> 主 题：[DISCUSS] Tests vs multiline strings
>
> Hi,
>
> Calcite tests sometimes require multiline strings.
> For instance: input SQL, output plan.
>
> TL;DR: let's use Kotlin to improve test code readability. Wha
for
multiline strings), like RelOptRulesTest does.
- Haisheng
--
发件人：Vladimir Sitnikov
日 期：2019年12月15日 06:09:37
收件人：Apache Calcite dev list
主 题：[DISCUSS] Tests vs multiline strings
Hi,
Calcite tests sometimes require multiline strings
Hi,
Calcite tests sometimes require multiline strings.
For instance: input SQL, output plan.
TL;DR: let's use Kotlin to improve test code readability. What do you think?
Unfortunately, Java <14 lacks multiline strings, so the current tests are
not that pretty :(
They are hard to read, hard to
12 matches
Mail list logo
