fix(.net): missing dynamic type checking for collection-nested unions #3720
Conversation
| return `${interpolates}"System.Collections.Generic.IDictionary<string, ${elementTypeName}>"`; | ||
| default: |
There was a problem hiding this comment.
Tweaked here, because nameof on the generic type does not produce a string that is human-friendly, unfortunately.
comcalvi
left a comment
There was a problem hiding this comment.
That was pretty fast, well done!
| } | ||
| } | ||
|
|
||
| abstract class Validation { |
There was a problem hiding this comment.
Should I use this approach in the Java code gen as well, or stick to the previous way?
There was a problem hiding this comment.
You can if you want, but you can also migrate in a separate PR.
| .digest('hex') | ||
| .slice(0, 6)}`; | ||
|
|
||
| code.openBlock(`switch (${expression})`); |
There was a problem hiding this comment.
Do we want this to be consistent across languages when possible? Should I port this switch approach to Java as well, or leave it as-is?
There was a problem hiding this comment.
You can't do switch like this in Java... it only works with primitive types, enums, String, and certain boxed primitive classes. So you end up having to stick to if/else here, sorry!
|
Thank you for contributing! ❤️ I will now look into making sure the PR is up-to-date, then proceed to try and merge it! |
|
Merging (with squash)... |
The .NET runtime type checking was not checking type unions that
are nested within a collection (list or map), although this is
necessary since the
is <type>guard does not allow making anyassumption about the contents of the collection.
This adds the missing checks, and replaces the guard clauses
with a
switchstatement using pattern matching, resultingin somewhat more elegant code (also with better
nullsafety).By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.