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
Implementation for automatically registering sealed serializers in polymorphic modules #2201
base: dev
Are you sure you want to change the base?
Conversation
f548387
to
1aead70
Compare
Hi, thanks for the PR! Feature is indeed looks useful, although I'm a reluctant about changing the behavior of existing function (it didn't throw exception on sealed classes before, so it's not adding a completely new functionality). Have you though about other possibilities of doing this? Like adding new |
I'll update the pull request later when I have time. While this introduces "changed" behaviour the current (without this request) implementation is not actually valid. As sealed classes (and interfaces) are abstract they don't actually make valid serializers in the polymorphic case. For serialization the value with never be directly of the sealed type, for deserialization it will never create a sealed instance. The only challenge with changing existing behaviour is when existing code does register the base for polymorphic serialization, this could have 2 consequences:
As the current code doesn't (appear to) throw an exception in case sealed parent is registered it may be best to use a separate function name. I'll update this in the pull request. |
@sandwwraith At a glance, no. #1865 is a different use case.
I don't have the types available at compile time, thus I can't register them in a serial module as you would 'normally' do. My use case is a framework in which the app building on top of it links in additional types, through reflection, which extend from an interface defined in the framework. The framework then supports serializing aggregations of such extending classes. I haven't looked at whether I could somehow create a |
I've updated the pull request by a split out function (although the tests that were deleted - and no longer are did verify that passing a sealed type serializer should fail for subclass). |
d584677
to
dfae643
Compare
…aled children of a class for polymorphic serialization of a shared (non-sealed) type.
…avoid casting warnings). Use a map to allow faster lookup of serializers to class (to allow for overlapping hierarchies).
dfae643
to
2e509cd
Compare
@Whathecode The thing this pull request does is support the case where there is a polymorphic base type |
This is an implementation for #2199 and #1865. This implementation just modifies the
subclass
method in the builder. It does (internally) expose the registered children inSealedSerializer
. It is not possible to trigger this behaviour from manually written serializers (instead ofSealedSerializer
).This does also remove the prohibition of registering sealed classes, but note that it will register the children of the sealed class, but not the sealed parent itself. The code does allow for overlaps (by ignoring the registration in this case) to accommodate overlapping hierarchies (although this can be abused in some ways) - it does mean that sealed child serializers can be manually overridden by registering the sub-serializer before the sealed parent.