Candidates for removal deprecation #1473
Conversation
| @Deprecated(MESSAGE_SHORTCUT_1_0, ReplaceWith("into { pathOf(column) }"), DeprecationLevel.ERROR) | ||
| @Refine | ||
| @Interpretable("MoveInto0") | ||
| public fun <T, C> MoveClause<T, C>.into(column: String): DataFrame<T> = pathOf(column).let { path -> into { path } } |
There was a problem hiding this comment.
Do you remember why we want to remove it? It's supported by compiler plugin, seems useful
There was a problem hiding this comment.
is it just rename {}.into {} maybe? or move {}.under("")?
There was a problem hiding this comment.
it's move { myCol }.toTop().rename { myCol }.into("newName")
There was a problem hiding this comment.
Well, I really don't see a reason 😄 . Let's keep it.
| // region DataFrame | ||
|
|
||
| @CandidateForRemoval | ||
| @Deprecated(MESSAGE_SHORTCUT_1_0, ReplaceWith("columns().toDataFrame().cast()"), DeprecationLevel.ERROR) |
There was a problem hiding this comment.
we also usually put the replaceWith contents in the deprecations file. I'm impartial to it, as long as we have at least one constant String there to track the deprecations
There was a problem hiding this comment.
I don't like it, because it's hard to validate when it's remote, especially in singular cases + losing IDE code analysis.
And btw we have a lot of them in the project:
|
should we immediately go to ERROR? I don't think many of these overloads hurt. So while we will clean them up, I wouldn't say there's much hurry, so WARNING could suffice |
| col.type() shouldBe typeOf<AnyRow>() | ||
| col.kind() shouldBe ColumnKind.Group | ||
| col[0] shouldBe row | ||
| @Suppress("DEPRECATION_ERROR") |
There was a problem hiding this comment.
If we deprecate them, we should probably remove any internal uses
There was a problem hiding this comment.
for DataRow.isEmpty(), I'd make it internal after deprecation and public removal for such tests.
Fixes #1028.