I've used the new version calcite with new version of IntelliJ, everything works. I like that. I can see valadmir put some efforts in this, I respect that. and all effort put in to the codebase should be respected. from my side, I don't contribute as much now, but occasionally I would look at the new stuff added so as long I can REPL the code I am okay with it. as for 'kotlin', like when it was first brought up in the calcite mail thread, I am curious about that and would be willing to learn more.
On Wed, Dec 18, 2019 at 7:45 AM Michael Mior <mm...@apache.org> wrote: > Le mar. 17 déc. 2019 à 15:26, Vladimir Sitnikov > <sitnikov.vladi...@gmail.com> a écrit : > > > > Vladimir>Quidem, CalciteAssert > > Michael>If you want to propose removing either of these, we could have a > > Michael>discussion about it, but you're talking about code which is > already > > Michael>heavily used throughout Calcite. > > > > The point of "we assume contributors are good at Java, thus we must keep > > the code to be Java-only" is weak. > > New contributors will likely see Quidem and CalciteAssert for the first > > time, and Java knowledge does not help there. > > > > I didn't make that point. Those are you words. > > > It does not imply that languages like Quidem and/or CalciteAssert are a > bad > > fit for their job, but it is wrong to judge > > based solely on "it is not Java". > > > > Michael>The consensus from the discussion you started seems to be that > > Michael>Kotlin should not be added to the tests > > > > It is not like that. > > I counted at least 5 different contributors stating they did not think > Kotlin should be introduced into test code. You seemed to be the only > one in the discussion strongly promoting it. If that's not consensus, > I must have misinterpreted the discussion. > > > > > Michael>I agree that for these specific tests, readability is improved > > > > That is exactly my point. There's an improvement, the downsides are > small, > > so I just committed it. > > > > Michael>But many tests require more than this > > > > That is to be discussed on a test by test basis (or use-case by > use-case). > > For instance, strings (especially, multi-line ones) with $ is an issue > for > > Kotlin for now. > > > > Vladimir > -- ~~~~~~~~~~~~~~~ no mistakes ~~~~~~~~~~~~~~~~~~
