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
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions