Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: encoding/json: Unmarshal support for dynamic types #13338

Closed
ANPez opened this issue Nov 20, 2015 · 5 comments
Closed

proposal: encoding/json: Unmarshal support for dynamic types #13338

ANPez opened this issue Nov 20, 2015 · 5 comments

Comments

@ANPez
Copy link

ANPez commented Nov 20, 2015

I'd love to see a version of json.Unmarshal that accepts a type selector. E.g. a function that, given the to-be-decoded json returns the type that should be unmarshalled.

This is very useful if you are reading a JSON array where the elements don't all have the same fields and you are ok with a heterogeneous array.

Say you have this JSON:

[{"a":1}, {"b":2}]

and you want the unmarshalled array to be like this

[]interface{}{A{A: 1}, B{B: 2}}

you could pass in a function to Unmarshal that, given the map[string]interface{} containing every one of the elements would return an empty struct to be unmarshalled to. These would, of course, slow the things down as it would require double unmarshalling.

@ianlancetaylor
Copy link
Contributor

What would the type of the empty struct be in your example? How would people use this in practice?

@ANPez
Copy link
Author

ANPez commented Nov 22, 2015

That empty struct would be the specific type, based on some information on the element itself. Could be something like this:

func getType(element map[string]interface{}) interface{} {
    if element["type"] == "type1" {
        return &structType1{}
    }
    return &structType2{}
}

GIven the returned empty struct, probably with anotations json:"..", json.Unmarshal would unmarshal into it, as usual.

@rsc
Copy link
Contributor

rsc commented Dec 28, 2015

I don't think this proposal makes a convincing case for the complexity being added. When does this come up? "If you are reading a JSON array where the elements don't all have the same fields..." but that doesn't sound like an array to me. Does anything in common use do this? We tend not to extend the standard library for hypotheticals.

Note also that you can already make a []map[string]interface{} and do this yourself. You can also use a []json.RawMessage and then process each array entry separately, as makes sense.

@rsc rsc added the Proposal label Dec 28, 2015
@rsc rsc added this to the Proposal milestone Dec 28, 2015
@ANPez
Copy link
Author

ANPez commented Dec 28, 2015

Makes sense when working with inheritance. Structs that embed others, and you want each of them to have their properties.

@adg
Copy link
Contributor

adg commented Aug 15, 2016

While I think this is a reasonable request, we need to stop making changes to the encoding/json package. It is already complicated enough, and changes introduce bugs. If this feature is important to people, it should be implemented in a package outside the standard library.

Closing this issue. Thanks for your time.

@adg adg closed this as completed Aug 15, 2016
@golang golang locked and limited conversation to collaborators Aug 15, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants