Overall, this is a very nice development that should also simplify the code base once we deprecate the expression parser!
Regarding method names, I agree with Seth that values/literals should use something like “lit()”. I also think that for column references we could use “col()” to make it clear that it is a column reference. What do you think? Aljoscha > On 28. Aug 2019, at 15:59, Seth Wiesman <sjwies...@gmail.com> wrote: > > I would prefer ‘lit()’ over ‘val()’ since val is a keyword in Scala. > Assuming the intention is to make the dsl ergonomic for Scala developers. > > Seth > >> On Aug 28, 2019, at 7:58 AM, Timo Walther <twal...@apache.org> wrote: >> >> Hi David, >> >> thanks for your feedback. I was also skeptical about 1 char method names, I >> restored the `val()` method for now. If you read literature such as >> Wikipedia [1]: "literal is a notation for representing a fixed value in >> source code. Almost all programming languages have notations for atomic >> values". So they are also talking about "values". >> >> Alteratively we could use `lit(12)` or `l(12)` but I'm not convinced that >> this is better. >> >> Regards, >> Timo >> >> [1] https://en.wikipedia.org/wiki/Literal_(computer_programming) >> >>> On 27.08.19 22:10, David Anderson wrote: >>> TImo, >>> >>> While it's not exactly pretty, I don't mind the $("field") construct. >>> It's not particularly surprising. The v() method troubles me more; it >>> looks mysterious. I think we would do better to have something more >>> explicit. val() isn't much better -- val("foo") could be interpreted >>> to mean the value of the "foo" column, or a literal string. >>> >>> David >>> >>>> On Tue, Aug 27, 2019 at 5:45 PM Timo Walther <twal...@apache.org> wrote: >>>> Hi David, >>>> >>>> thanks for your feedback. With the current design, the DSL would be free >>>> of any ambiguity but it is definitely more verbose esp. around defining >>>> values. >>>> >>>> I would be happy about further suggestions that make the DSL more >>>> readable. I'm also not sure if we go for `$()` and `v()` instead of more >>>> readable `ref()` and `val()`. This could maybe make it look less >>>> "alien", what do you think? >>>> >>>> Some people mentioned to overload certain methods for accepting values >>>> or column names. E.g. `$("field").isEqual("str")` but then string values >>>> could be confused with column names. >>>> >>>> Thanks, >>>> Timo >>>> >>>>> On 27.08.19 17:34, David Anderson wrote: >>>>> In general I'm in favor of anything that is going to make the Table >>>>> API easier to learn and more predictable in its behavior. This >>>>> proposal kind of falls in the middle. As someone who has spent hours >>>>> in the crevices between the various flavors of the current >>>>> implementations, I certainly view keeping the various APIs and DSLs >>>>> more in sync, and making them less buggy, as highly desirable. >>>>> >>>>> On the other hand, some of the details in the proposal do make the >>>>> resulting user code less pretty and less approachable than the current >>>>> Java DSL. In a training context it will be easy to teach, but I wonder >>>>> if we can find a way to make it look less alien at first glance. >>>>> >>>>> David >>>>> >>>>>> On Wed, Aug 21, 2019 at 1:33 PM Timo Walther <twal...@apache.org> wrote: >>>>>> Hi everyone, >>>>>> >>>>>> some of you might remember the discussion I started end of March [1] >>>>>> about introducing a new Java DSL for Table API that is not embedded in a >>>>>> string. >>>>>> >>>>>> In particular, it solves the following issues: >>>>>> >>>>>> - No possibility of deprecating functions >>>>>> >>>>>> - Missing documentation for users >>>>>> >>>>>> - Missing auto-completion for users >>>>>> >>>>>> - Need to port the ExpressionParser from Scala to Java >>>>>> >>>>>> - Scala symbols are deprecated! A Java DSL can also enable the Scala DSL >>>>>> one. >>>>>> >>>>>> Due to shift of priorities, we could not work on it in Flink 1.9 but the >>>>>> feedback at that time was positive and we should aim for 1.10 to >>>>>> simplify the API with this change. >>>>>> >>>>>> We propose the following FLIP-55: >>>>>> >>>>>> https://docs.google.com/document/d/1CfaaD3j8APJDKwzIT4YsX7QD2huKTB4xlA3vnMUFJmA/edit?usp=sharing >>>>>> <https://docs.google.com/document/d/1CfaaD3j8APJDKwzIT4YsX7QD2huKTB4xlA3vnMUFJmA/edit#heading=h.jn04bfolpim0> >>>>>> >>>>>> Thanks for any feedback, >>>>>> >>>>>> Timo >>>>>> >>>>>> [1] >>>>>> https://lists.apache.org/thread.html/e6f31d7fa53890b91be0991c2da64556a91ef0fc9ab3ffa889dacc23@%3Cdev.flink.apache.org%3E >>>>>> >>
