Skip to content

Feature Request: Allow deserialization of hyphenated fields #132

@Rkuro

Description

@Rkuro

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions