-
Notifications
You must be signed in to change notification settings - Fork 19
Description
What happened?
Describe what you've observed and why it's bad (please include whatever stacktraces/version numbers you can).
Clear steps to reproduce the behaviour are always helpful too!
A very common use case for this type of capability is the ability to easily serialize/deserialize typed objects from a shared interface, but we need the ability to be a bit more flexible when deserializing objects into Conjure classes or we're going to need to use a different tool to share interfaces (which would be a bummer since I think its the right tool here).
Example:
Input object (python dictionary):
{ "foo-bar": "baz" }
Desired Conjure Object:
Banana(foo_bar: baz)
Currently - this will result in an empty Banana(FooBar: None) object which can potentially be misleading.
What did you want to happen?
I realize that having strict standards is generally a good thing, especially in an area with mostly solved problems (like IR object representation), so I am not proposing any changes in the default behavior.
Instead, I am arguing there should be a separate, non-standard set of "DecodingOptions" that should be available to the user upon request - with, for example, an option to loosen restrictions around deserialization and allow fields with hyphens to be able to deserialize into objects.
An implementation of what this might look like: PR- #131