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.
There was a problem hiding this comment.
move { myCol }.toTop().rename { myCol }.into("newName")
or, you know move { myCol }.into(pathOf("newName")) ;P
There was a problem hiding this comment.
but yes, let's keep it, as we treat column paths and the String API as the same thing :)
| // 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.
There was a problem hiding this comment.
good idea! But we should put somewhere that we will make it internal maybe. Or should we have this deprecation suppression mechanism being seen as "we're planning not to remove it but to make it internal"?
Fixes #1028.