-
Notifications
You must be signed in to change notification settings - Fork 620
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
Wrapping a type's serializer with another without changing the actual type #2699
Comments
|
@pdvrieze although that makes sense for my use case (and I would love to know how to do that), it won't make sense for all use cases. |
@Laxystem Have a look at https://gist.github.com/pdvrieze/0eb34ab2f914383a4d98cfc414272ac7 For some formats (such as XML) you might also need to handle wrapping the |
@pdvrieze thanks! Would you mind me using it as a reference for a MPL 2.0-licensed project? |
Go ahead |
Problem: how can I identify when it is required? Intuitively, I think of annotations - but is there a better way? Afterall, afaik I can't use the |
@Laxystem You can either use annotations with |
Got it, thanks. I'll just add |
Can't this be solved with just #292 ? |
What is your use-case and why do you need this feature?
I am implementing a JsonLD library for Kotlin/Multiplatform.
However, I've encountered a problem: expanded JsonLD has lots of "useless" contracts like
[{"@value":"etc..."}]
, meaning just"etc..."
.To solve this issue, I create custom serializers that wrap the original type's serializer. There are three ways I can do so:
Functional<T>
instead ofT
.obj.property.value
instead of justobj.property
.@Serializable(with = Functional::class)
.Functional
.Describe the solution you'd like
My initial solution
Add the
with
parameter toMetaSerializable
, and allow serializers to get the serializer of the type they're of (serializer<T>()
given@Functional T
) as a constructor parameter.And why it potentially won't work
The first part of my solution is alright. The second part, however, can be argued to be problematic design-wise - it could lead to annotations being chained order-dependently (something never seen before in Kotlin nor Java as far as I'm aware).
An alternative
Wait for Kotlin to support expanding type aliases to type parameters (see KT-68757).
The text was updated successfully, but these errors were encountered: