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,
Replace $ with something else will have a large impact. E.g. projects using
Calcite might have tests that verify plans by plan.toString() thus $ is
exposed in many places.
Can we only use Kotlin for tests that does not evaluate plans? I think
there are still many tests that does not have "$" can
The plan becomes not so easier to read, which is more important to me.
Unless we change $ to other symbol, I am inclined to keep using Java.
I am not sure why schemas in MaterializationTest require column names to be
quoted, If we can change that, queries will be much easier to read (even for
11 matches
Mail list logo
