Skip to content
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

codegen-java/kotlin: Support generating sealed classes #803

Open
odenix opened this issue Nov 12, 2024 · 4 comments
Open

codegen-java/kotlin: Support generating sealed classes #803

odenix opened this issue Nov 12, 2024 · 4 comments

Comments

@odenix
Copy link
Contributor

odenix commented Nov 12, 2024

It would be very nice to generate sealed Java/Kotlin classes whenever possible. This would improve code comprehension, pattern matching, and the IDE experience.

Potential solutions:

  1. Infer which abstract and open Pkl classes can be sealed in Java/Kotlin.
    At a minimum, this would require passing all Pkl modules at once to Java/KotlinCodeGenerator so that it can check if a class is subclassed in another module. Currently, Java/KotlinCodeGenerator only accepts a single module whereas CliJava/KotlinCodeGenerator accepts multiple.
  2. Support sealed classes in Pkl. This feels like a cleaner solution and could prove equally useful as supporting open vs. non-open classes.
@bioball
Copy link
Contributor

bioball commented Nov 13, 2024

Infer which abstract and open Pkl classes can be sealed in Java/Kotlin.

Without a sealed in Pkl, there's no way to ensure that the provided set of classes is exhaustive. For example:

  1. Library publishes Pkl bindings + Java codegen'd classes
  2. Application uses library, extends Pkl classes and does is own codegen

@odenix
Copy link
Contributor Author

odenix commented Nov 13, 2024

I think the conclusion is that moving forward with this feature would require a sealed SPICE.

@bioball
Copy link
Contributor

bioball commented Nov 13, 2024

Yeah; I think that's right

@odenix
Copy link
Contributor Author

odenix commented Nov 15, 2024

How about reserving the keyword sealed for now?

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

No branches or pull requests

2 participants