Why is `ComplexObjectModelBinder` sealed?

[miloush]

The ComplexObjectModelBinder is the only binder under src/Mvc/Mvc.Core/src/ModelBinding/Binders that is sealed and I would like to understand the reasons.

People seem to keep running into this (#48673 #47039 #46775 #33545 and several on SO), with the last one suggesting to copy the code even though it was pointed out it it relies on other internal types.

The question was asked in #46775 but a workaround was sought instead, hence the question - why was this binder made sealed?

[captainsafia]

@miloush Thanks for filing this issue! The type was originally sealed to make it easier to modify the behavior of that class without worrying about 3rd party implementors. We also have a policy around sealing types for performance reasons if we don't feel there's compelling motivations to derive.

As you mentioned, there's been a fair bit of interest in unsealing the type over the years so we can consider bubbling this up in our API review.

Out of curiousity, have you had any luck with the provided workarounds?

[miloush]

Thank you @captainsafia. I am not quite sure the performance gains from sealing the type are interesting compared to the reflection costs the binder has to go through, but I can see the appeal of not needing to commit to a design in the early stages of development. Since the ComplexObjectModelBinder is superseding ComplexTypeModelBinder which was not sealed, I wonder whether you have run into any of such issues with the previous iteration. Are the differences between behaviors of ComplexTypeModelBinder and ComplexObjectModelBinder documented anywhere?

Note that for the unsealing to be useful, some of the members would need to be come protected.

No I did not manage to tweak the behavior of the binding the way I wanted, I ended up changing the client side code to meet the binder capabilities.