Thanks for your feedback Rong. You are right, we can still have shorter
names if the user feedback demands that. Adding additional shorter
method names is always possible. So let's stick to lit() for now.
I converted the Google document into a wiki page:
https://cwiki.apache.org/confluence/dis
Thanks for putting together the proposal @Timo and sorry for joining the
discussion thread late.
I also share the same thought with Fabian on the ease-of-use front. However
I was wondering if we need to start the expression design with them?
One thing I can think of is: is it possible to support "
Hi all,
I see a majority votes for `lit(12)` so let's adopt that in the FLIP.
The `$("field")` would consider Fabian's concerns so I would vote for
keeping it like that.
One more question for native English speakers, is it acceptable to have
`isEqual` instead of `isEqualTo` and `isGreater` i
Hi,
IMO, we should define what we would like to optimize for:
1) easy-to-get-started experience or
2) productivity and ease-of-use
While 1) is certainly important, I think we should put more emphasis on
goal 2).
That's why I favor as short as possible names for commonly used methods
like column r
I'm fine with `lit()`. Regarding `col()`, I initially suggested `ref()`
but I think Fabian and Dawid liked single char methods for the most
commonly used expressions.
Btw, what is your opinion on the names of commonly used methods such as
`isEqual`, `isGreaterOrEqual`? Are we fine with the cur
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 cle
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 wrote:
>
> Hi David,
>
> thanks for your feedback. I was also skeptical about 1 char method names,
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 at
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 val
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()` instea
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 keepin
11 matches
Mail list logo
