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
gocty: Too inflexible about map vs. object distinction #17
Comments
zclconf/go-cty#17 means we can't decode a nested block type that has dynamically-typed attributes into a Go map directly, so for now we'll do the decoding more manually until that upstream issue is fixed.
I am not sure it's connected with topic, but I have problem with cty.Maps and cty.Objects, please point me if I'm wrong.
I receive error:
Ok, unconsistent map fields/keys ! I need to use cty.Object, cos it have flexible types!
But it also doesn't work for me:
because ctyList wants to keep the equal structures in container. It's OK, it's golang way. But in Golang we have |
Hi @doctornkz, If you want to have a sequence where each element has its own type, I think tuple types are what you are looking for. You can use a tuple type instead of a list type to track each element value separately. |
Thank you Martin, Thank you! |
gocty
was written quite early on when maps and objects were thought of as very distinct ideas with different operations.In the meantime, we've blurred that a little by allowing some of the collection operations to also work for object types, since that tends to be more convenient for calling applications that can therefore share code between the two.
Currently the
gocty
logic is quite picky about the distinction between these, requiring that objects be decoded into structs and maps be decoded into maps. It would be helpful to callers, and more consistent with how the maincty
has evolved, to allow decoding objects into Go maps (as long as the attributes all conform to the Go element type) and to allow decoding maps into Go structs, where compatible.The text was updated successfully, but these errors were encountered: