Remove Iterable overloads for selecting columns in favor of `select { iterable.toColumnSet() }`

[Jolanrensen]

Many functions in DataFrame have overloads, as you know. One of the common operations handled in a lot of functions is selecting columns. This happens in the df.update() function, df.select(), df.fillNulls() etc. Overloads of these functions allow the user to give the columns they want to select in the following ways:

• vararg KProperty (https://kotlin.github.io/dataframe/kpropertiesapi.html)
  Iterable of KProperty
• vararg String of column names (https://kotlin.github.io/dataframe/stringapi.html)
• Iterable of String column names
• vararg Column reference (https://kotlin.github.io/dataframe/columnaccessorsapi.html)
• Iterable of Column reference
• The column selector DSL {} (includes all APIs above and https://kotlin.github.io/dataframe/extensionpropertiesapi.html)

However, not all operations seem to have all overloads at the moment:
For instance, select does not have the Iterable of KProperty.
update and fillNaNs do not have Iterable of KProperty and Iterable of Strings.
and so every operation seems to have its own subset of these overloads.

Let's remove the Iterable overloads altogether and check the presence of the other (vararg) functions.
Of course, we need to provide easy ReplaceWith("this.select { columns.toColumnSet() }") deprecations so we need some additions to the public API to make sure users of the Iterable functions can transition easily by adding:

• Array<KProperty<T>>.toColumnSet(): ColumnSet<T>
• Iterable<KProperty<T>>.toColumnSet(): ColumnSet<T>
• Array<String>.toColumnSet(): ColumnSet<Any?>
• potentially <T> Array<String>.toColumnSetOf(): ColumnSet<T>
• Iterable<String>.toColumnSet(): ColumnSet<Any?>
• potentially <T> Iterable<String>.toColumnSetOf(): ColumnSet<T>
• Array<ColumnReference<T>>.toColumnSet(): ColumnSet<T>
• Array<Iterable<T>>.toColumnSet(): ColumnSet<T>

[koperagen]

Maybe it worth to add "columnSetOf(arg)" operation for discoverability or check if something like this already exists. From time to time i forget about extension functions in DSL API such as AggregationDsl, AddDsl (i.e. into, invoke, from etc), because normally they won't show up in the completion. (i wonder if it can be fixed on IDE side?..) You can find them either in docs or in source code. But my intuitive approach with Kotlin libraries is that everything i could do can be found in completion.

[Jolanrensen]

For columnSetOf(arg) I expect the arg to be a vararg, similar to listOf, setOf, etc. ColumnSet.from() is probably more idiomatic.
For the completion: yes and no. It's good that not everything shows up in the completion. Especially when you cannot call a function except from within a DSL. This avoids clutter. I usually just search for usages of a certain type as return type to see how it's created across the library.

[koperagen]

For columnSetOf(arg) I expect the arg to be a vararg, similar to listOf, setOf, etc. ColumnSet.from() is probably more idiomatic.

Agree about naming, but from as a member of a companion object? I'm not sure about it. My initial idea was making it a part of SelectDsl. I don't see how not seeing all API of some DSL helps to avoid clutter. Maybe i misunderstood you and it's about global functions?

[Jolanrensen]

from in the companion object is just a Factory pattern I think (like a constructor, but instantiating something using something else, like Json.parse()). It's similar to extension functions but the other way around.

Right, I meant cluttering the global scope. Now I see what you mean about extension functions inside the DSL too.
Stuff like into should indeed be visible when inside the DSL. Maybe in a live-template like manner? Like a user types "into", enter and the receiver part before into is selected, the user types a name, enter, the part after into is selected, enter.

But... I do think we should limit this to live-templates or something, I don't think showing all extension functions everywhere would be a good idea.

[koperagen]

Right, I meant cluttering the global scope. Now I see what you mean about extension functions inside the DSL too. Stuff like into should indeed be visible when inside the DSL. Maybe in a live-template like manner? Like a user types "into", enter and the receiver part before into is selected, the user types a name, enter, the part after into is selected, enter.

That would be cool! At least for scopes with "this"