Add missed OverloadAccessApi deprecations in all.kt, cols.kt

[koperagen]

Interesting that i also deprecate some of the APIs we have compiler support for:

AllAfter0
Cols0
AllBefore2

df.select { cols(a, b) }, df.select { allAfter(b) } and df.select { allBefore(b) }

They're generally nice and useful, aren't they? Let's have one round of "undeprecation" some time later and decide what ColumnReference APIs we'd like to keep #1698

[Jolanrensen]

They're generally nice and useful, aren't they? Let's have one round of "undeprecation" some time later and decide what ColumnReference APIs we'd like to keep #1698

Honestly, I'm not sure I feel comfortable having any Beta release with cols(a, b) being deprecated. I use it Often (with a capital O!). Especially to avoid long and chains.

df.select { cols(a, b, c, d, e) }

is waaaay more readable and typable than

df.select { a and b and c and d and e }

(I mean, there's a reason we have commas in our own language, no? ;P)

If we do the undecprecation cycle before beta5, I'm fine with this, but otherwise I don't think it's a good idea to deprecate it, even if temporarily.

Having all KProperties overloads deprecated is an earlier oversight by us of course :)

[koperagen]

ok, in this case let me update the PR. But i suspect we still might need undeprecation cycle

[koperagen]

Check last commit - looks like we have a lot of cases where in CS DSL we actually need to keep ColumnRefernce overload. Different story from top level APIs, right?