Skip to content

To type overloads with diff nullability#1839

Open
Allex-Nik wants to merge 2 commits into
masterfrom
to-type-overloads-diff-nullability
Open

To type overloads with diff nullability#1839
Allex-Nik wants to merge 2 commits into
masterfrom
to-type-overloads-diff-nullability

Conversation

@Allex-Nik

@Allex-Nik Allex-Nik commented May 4, 2026

Copy link
Copy Markdown
Collaborator

Fixes #1695

However, after the removal of the overloads, the compiler plugin produces the expected schema only since the version 2.4.0. So it's probably better to postpone merging this PR till the 2.4.0 release.

@Allex-Nik Allex-Nik requested a review from koperagen May 4, 2026 08:36
@Allex-Nik Allex-Nik force-pushed the to-type-overloads-diff-nullability branch from f23c7ed to 325ac42 Compare May 8, 2026 10:14
assertNullabilityPreserved(converted, typeOf<IMG>())
}

// @Test

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

toUrl/toURL throw NoClassDefFoundError. Seems like they have the same signature which causes a conflict in case insensitive environment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Created #1903 about it

* @return A new [DataFrame] with the values converted to [LocalDate].
*/
@JvmName("toLocalDateFromTInt")
@JvmName("toLocalDateFromTIntNullable")

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should it be corrected like that?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for correctness, yes, but that breaks binary compatibility :/ on the other hand, removing all these overloads also breaks it, so it's probably fine.

Since we're breaking binary compatibility anyway, maybe you could try removing as many @JvmNames as possible? Many won't be needed anymore now

@Refine
@Converter(IMG::class, nullable = false)
@Interpretable("ToSpecificType")
public fun <T, R : URL?> Convert<T, URL>.toImg(width: Int? = null, height: Int? = null): DataFrame<T> =

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need the R?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think R should have been the second argument in Convert<>

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I continued the topic here :)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably it should be removed indeed

toJavaLocalDate(formatter = pattern?.let { DateTimeFormatter.ofPattern(pattern) }, locale = locale)
.convert(this.columns).toLocalDate()

@Deprecated(

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't test these last 3 deprecated functions: when I use it in a test, the compile time schema of the converted dataframe contains String and String?. I didn't investigate it further because first I wanted to ask if we need to test them at all :)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, they seem to miss compiler plugin annotations, not sure why

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's ok to not test them

@@ -1004,28 +978,6 @@ public fun <T> Convert<T, URL>.toIFrame(
public fun <T, R : URL?> Convert<T, URL?>.toImg(width: Int? = null, height: Int? = null): DataFrame<T> =

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we make R the second argument in Convert?

public fun <T, R : URL?> Convert<T, R>.toImg...

Would it be wrong to remove R instead?

public fun <T> Convert<T, URL?>.toImg...

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

R is unused, no? It can probably be removed, it might be a mistake :)

@Allex-Nik Allex-Nik force-pushed the to-type-overloads-diff-nullability branch from 325ac42 to 9474385 Compare June 18, 2026 13:59
@Allex-Nik Allex-Nik marked this pull request as ready for review June 18, 2026 14:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Remove redundant toType overloads with different nullability in convert API

3 participants