Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Reflection has A Problem: We want to support using `attr.Value`s inside of structs, slices, etc. and just having the reflection package Do The Right Thing. This means the reflection package needs to be able to create them. We originally solved that in #30 by just instantiating empty values of their type, and then calling a `SetTerraformValue` method on that value. This was super annoying, because then we needed two methods for getting an `attr.Value` set to the right values: `attr.Type.ValueFromTerraform` and `attr.Value.SetTerraformValue` were basically the same thing. But whatever, it worked. Except, no it didn't. Complex types like lists and maps store their element/attribute types as properties on their structs. It's important that these be set. Only the `attr.Type` has this information, it's not passed in as part of the `tftypes.Value`. So reflect couldn't set those values, and produced broken `attr.Value`s as a result. (Their `ToTerraformValue` methods would run into trouble, because they wouldn't know what `tftypes.Type` to use for elements or attributes). To solve this problem, we decided to supply the `attr.Type` from the schema to the reflect package, wiring it through so that we could instantiate new `attr.Value`s when the opportunity presented itself. This solves our problem, because we got rid of the `attr.Value.SetTerraformValue` method and used the `attr.Type.ValueFromTerraform` directly to just instantiate a new value, which made sure it was set up correctly. But now we have a new problem: what if the `attr.Type` in the schema doesn't produce the `attr.Value` they're trying to assign to? We decided to just throw an error on that one, because there's no reasonable way around it. Depends on #44.
- Loading branch information