mirror of
https://github.com/apple/pkl.git
synced 2026-01-13 23:23:37 +01:00
Missing union type support for Kotlin codegen #15
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @madisp on GitHub (Feb 3, 2024).
Bit of a tall ask, I know, but it'd be wonderful if we could map union types into some form of Kotlin structure.
@bioball commented on GitHub (Feb 4, 2024):
It'd be great to support this, but it's not clear how they should turn into Kotlin. Feel free to provide suggestions, though.
@jamesward commented on GitHub (Feb 4, 2024):
For now this will have to be implemented with
sealed classhttps://kotlinlang.org/docs/sealed-classes.html@madisp commented on GitHub (Feb 4, 2024):
yup, most likely.
sealed classneeds a name though, maybe take a similar approach to string union to enum mapping that all union types should be defined via a type alias?E.g. this wouldn't still map to Kotlin:
but this would?
@giordano-newday commented on GitHub (Jul 1, 2024):
Hi all, I'm evaluating pkl as a configuration language for an API GW. My server is in Kotlin and not having union mapped to Kotlin (or Java) is a show stopper.
There any thoughts about adding them? or what would be a workaround for something with the same semantic but supported by Kotlin?
My scenario is something like
typealias HttpMethod = "GET" | "POST" | "PUT" | "DELETE"Thanks
@bioball commented on GitHub (Jul 1, 2024):
@giordano-newday: We don't have a great way to model most union types as Kotlin, because it's missing anonymous sum types. However, typealiases of string literal unions are a special case, and are no problem to represent.
This pkl:
Turns into the following Kotlin:
@giordano-newday commented on GitHub (Jul 1, 2024):
I think it would for my scenarios. Thanks @bioball.
@devinrsmith commented on GitHub (Jul 18, 2025):
A strategy I've used to implement union types before involves defining an interface with a Visitor callback that has methods for each of the union types. In some domains, the specific items in the union could extend the union type themselves, but in a general purpose system where the same type might be in multiple unions, it's probably best to have an internal wrapper type. Here's a quick example of something that could be considered:
Somewhat orthogonal (as in, this could be done alongside the callback pattern), but potentially easier to conceptualize / use: