-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use a consistent interface for Tables where input type cannot be converted #12
Comments
I don't like
just because For that reason I think
is the best option, and let the user append the result to the table explicitly |
If we really wanted
It should probably be a third function, like or
|
It also gives them the flexibility to name it accordingly. Otherwise we'd have to come up with a naming convention in the package ☠️
A slightly roundabout (but feasible) way is also # for DataFrames
df.transformed = apply(df, ::Transform; kwargs...)
# for NamedTuples
x = apply(nt, ::Transform; kwargs...)
merge!(nt, (transformed=x,)) but if we had to make a single function call I'd prefer |
I'm uncertain about this. There's a more general question of what operations on Tables we want to provide, vs. leaving to the user.
Currently, we have an
apply!
for tables that mutates the table columns in-place.However this doesn't work when the input type can't be converted to the output type, e.g. from DateTime to Int for the hour-of-day transform. We could replace the column with the new type, but users should have a choice whether to do such a "strong" mutation.
Alternatively we could have an
apply!
that appends the new columns to the Table.We could also have an
apply
that returns the transformed columns on their own (example), which gives users the most flexibility.The text was updated successfully, but these errors were encountered: