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 >>>>> >
