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

Implement OptionalAttributes for Objects. #74

Merged
merged 4 commits into from
Apr 15, 2021
Merged

Conversation

paddycarver
Copy link
Contributor

This is another massive PR, sorry. I tried to separate out some of the
changes, but the code kept overlapping, unfortunately.

All our Types got an Equal method, so they can be compared using go-cmp.
This was necessary to make the tests pass. As part of this, the Type
interface was refactored to include an equals() private method, which
powers the Equal and Is methods on each type.

I also fixed some periods in error messages to make golint happy.

Of course, with these new methods, there was enough logic to add tests
to each Type, so I added some tests that exercised the equality checks.

I also added, which was the main thing I was trying to do here, an
OptionalAttributes property to Objects. These are attributes that can
be set on an object, but are not required to be.

Because OptionalAttributes made the NewValue logic more complicated for
Objects, I wrote some tests for creating Objects with NewValue to test
the logic.

Finally, the new Object comparison logic was panicking during a
tfprotov5 / tfprotov6 test, because the Object had a nil AttributeTypes
map instead of an empty AttributeTypes map. I fixed it to use an empty
AttributeTypes map. In theory, I don't think we should ever see a nil
AttributeTypes map.

Fixes #48.

@paddycarver paddycarver added the enhancement New feature or request label Apr 13, 2021
@paddycarver paddycarver requested a review from a team April 13, 2021 01:02
@paddycarver
Copy link
Contributor Author

Tests are fixed by #72, will rebase this on top of it once it's merged.

This is another massive PR, sorry. I tried to separate out some of the
changes, but the code kept overlapping, unfortunately.

All our Types got an Equal method, so they can be compared using go-cmp.
This was necessary to make the tests pass. As part of this, the Type
interface was refactored to include an equals() private method, which
powers the Equal and Is methods on each type.

I also fixed some periods in error messages to make golint happy.

Of course, with these new methods, there was enough logic to add tests
to each Type, so I added some tests that exercised the equality checks.

I also added, which was the main thing I was trying to do here, an
OptionalAttributes property to Objects. These are attributes that _can_
be set on an object, but are not _required_ to be.

Because OptionalAttributes made the NewValue logic more complicated for
Objects, I wrote some tests for creating Objects with NewValue to test
the logic.

Finally, the new Object comparison logic was panicking during a
tfprotov5 / tfprotov6 test, because the Object had a nil AttributeTypes
map instead of an empty AttributeTypes map. I fixed it to use an empty
AttributeTypes map. In theory, I don't think we should ever see a nil
AttributeTypes map.
@paddycarver paddycarver force-pushed the paddy_optional_attrs branch from 8162ddd to a7e10ec Compare April 14, 2021 00:33
@paddycarver paddycarver merged commit 5b067e3 into main Apr 15, 2021
@paddycarver paddycarver deleted the paddy_optional_attrs branch April 15, 2021 23:05
paddycarver added a commit that referenced this pull request Apr 18, 2021
Fix the checks that NewValue runs to ensure that a value can be used
with a Type to properly handle DynamicPseudoTypes nested in complex
types. Builds on and supersedes #76.

Should we make this part of the behavior for `.Is`? My gut says "no",
because `Is` is supposed to be about checking whether a type is
semantically similar, not that it can be used as another type. Maybe we
want a `Fulfills` method, similar to Is, that does this? I don't know
that this behavior needs to be exported, though...

Fixes a bug in #74 that would panic for complex types containing
DynamicPseudoTypes.
paddycarver added a commit that referenced this pull request Apr 20, 2021
Fix the checks that NewValue runs to ensure that a value can be used
with a Type to properly handle DynamicPseudoTypes nested in complex
types. Builds on and supersedes #76.

Should we make this part of the behavior for `.Is`? My gut says "no",
because `Is` is supposed to be about checking whether a type is
semantically similar, not that it can be used as another type. Maybe we
want a `Fulfills` method, similar to Is, that does this? I don't know
that this behavior needs to be exported, though...

Fixes a bug in #74 that would panic for complex types containing
DynamicPseudoTypes.
paddycarver added a commit that referenced this pull request Apr 21, 2021
Fix the checks that NewValue runs to ensure that a value can be used
with a Type to properly handle DynamicPseudoTypes nested in complex
types. Builds on and supersedes #76.

Should we make this part of the behavior for `.Is`? My gut says "no",
because `Is` is supposed to be about checking whether a type is
semantically similar, not that it can be used as another type. Maybe we
want a `Fulfills` method, similar to Is, that does this? I don't know
that this behavior needs to be exported, though...

Fixes a bug in #74 that would panic for complex types containing
DynamicPseudoTypes.

Co-authored-by: Paul Tyng <[email protected]>
Copy link

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 28, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add support for OptionalAttrs inside tftypes.Objects
2 participants