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

gocty: Too inflexible about map vs. object distinction #17

Open
apparentlymart opened this issue Mar 17, 2019 · 3 comments
Open

gocty: Too inflexible about map vs. object distinction #17

apparentlymart opened this issue Mar 17, 2019 · 3 comments
Labels
enhancement gocty Conversions to and from native Go types

Comments

@apparentlymart
Copy link
Collaborator

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 main cty 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.

@apparentlymart apparentlymart added enhancement gocty Conversions to and from native Go types labels Mar 17, 2019
apparentlymart added a commit to apparentlymart/terraform-provider-testing that referenced this issue Mar 17, 2019
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.
@doctornkz
Copy link

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 need to create the structure - List of Maps. [{},{},...].
Obviously, I should to use cty.ListVal around ctyMapVal.
As example:

func main() {
	myMap := cty.MapVal(map[string]cty.Value{
		"test":  cty.NumberIntVal(1),
		"test3": cty.StringVal("test3"),
	})
	myMap2 := cty.MapVal(map[string]cty.Value{
		"test1": cty.NumberIntVal(1),
		"test2": cty.StringVal("test6"),
	})
	var rows []cty.Value
	rows = append(rows, myMap)
	rows = append(rows, myMap2)
	myList := cty.ListVal(rows)
	fmt.Printf("%v", myList)
}

I receive error:

panic: inconsistent map element types (cty.Number then cty.String)

Ok, unconsistent map fields/keys ! I need to use cty.Object, cos it have flexible types!

		myMap := cty.ObjectVal(map[string]cty.Value{
			"test":  cty.NumberIntVal(1),
			"test3": cty.StringVal("test3"),
		})
		myMap2 := cty.ObjectVal(map[string]cty.Value{
			"test1": cty.NumberIntVal(1),
			"test2": cty.StringVal("test6"),
		})
		var rows []cty.Value
		rows = append(rows, myMap)
		rows = append(rows, myMap2)
		myList := cty.ListVal(rows)
		///fmt.Printf("%v", myList)

But it also doesn't work for me:

panic: inconsistent list element types (cty.Object(map[string]cty.Type{"test3":cty.String, "test":cty.Number}) then cty.Object(map[string]cty.Type{"test1":cty.Number, "test2":cty.String}))

because ctyList wants to keep the equal structures in container. It's OK, it's golang way. But in Golang we have interface{} to create list of any types. What is the correct way for cty here?

@apparentlymart
Copy link
Collaborator Author

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.

@doctornkz
Copy link

doctornkz commented Jul 4, 2019

Thank you Martin, Thank you!
... 15 min later...
It works!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement gocty Conversions to and from native Go types
Projects
None yet
Development

No branches or pull requests

2 participants