Add df.properties() function to improve visibility of generated API for typed column access

[koperagen]

It's not always easy to tell if code generation in notebooks or compiler plugin worked as expected or find columns you're interested in without printing schema. With this change, people will have an option to overview generated column properties

In notebooks:

val df = DataFrame.read("file.csv")
==== next code cell
df. // column properties are mixed together with methods, not easy to find unless you already know names
df.properties(). // easy to overview available columns

In compiler plugin:

val df = @Import DataFrame.read("file.csv")
df.properties().

[Jolanrensen]

It will clash if you have df.group { a and b }.into("columns"), right?
I suspect this is the reason we have df.size df.size(), df.nrow df.rowsCount(), etc in the public api.
Only functions, no properties. Now, df.columns() already exists, but maybe df.columnScope() could work?

[koperagen]

Generated properties override "columns", so for users it means that they loose ability to overview columns if they have column with this name. It won't prevent them from accessing their "columns" column though. That's why i think it's a good trade off, no?

[Jolanrensen]

Hmm that means the API would have certain parts be available depending on the data.
I think this is not a good idea. It may create unexpected behavior and copy/pasting of examples failing, etc. Plus, it's a slippery slope to adding more properties to DataFrame and more potential clashes... So no, I would say we maintain our convention of not having any public properties to DataFrame, just the generated ones.

Functions are fine of course :)

[koperagen]

There's an important part: it's not available in selection dsl, so potential conflicts are limited to only df. column access. Generally, it's not even useful api - It's an utility to mitigate completion list clutter and the fact there's no good way to see generated code
We can simply agree to not add properties other than this one

df.columnsScope().columnGroup.columnsScope().

df.columns.columnGroup.columns.

[Jolanrensen]

Yes, but we'd still have conflicts that don't need to be there. What's wrong with making a function instead?
I think df.availableColumns(), or df.columnsScope(), for instance, would be a nice alternative that can never clash :)

[koperagen]

Because df.columns is a better name. We'd have conflicts - if someone wants to overview columns (which wasn't even possible before) and miraculously have "columns" in their dataframe

[Jolanrensen]

it's also an option to deprecate the old df.columns() -> df.getColumns() and migrate the functionality to this. That would be fine by me, but a property, I can't agree with

[zaleslaw]

I need a pause for a week to play with it

[koperagen]

Alternative option: function named properties. example: df.properties()

[zaleslaw]

I'd like properties more "https://kotlinlang.org/api/core/kotlin-stdlib/kotlin.collections/to-properties.html"
Maybe toProperties?

[Jolanrensen]

toProperties() indicates a conversion, something that's not really happening.

It's more like .getProperties() which in standard Kotlin would become the accessor: .properties.

In DataFrame, however, we make a distinction between columns accessors, in the form of generated properties (.colA, .colB), and helpers provided by us, which come in the form of .size(), .columns(), .columnsCount(), .columnTypes(), etc.

.properties() fits perfectly in this row :)

[Jolanrensen]

Useful! Thanks!