Module version
Use-cases
We're still using *tftypes.AttributePath all over the place, and that's really verbose to build and can be bothersome to work with, given how close it sticks to the protocol. We should come up with a framework-specific abstraction for attribute paths.
Ideally, this would be much less verbose without sacrificing any of the clarity. Perhaps just shortening the names would be enough?
This would also ideally solve problems we've seen in validation, etc. of wanting to be able to specify wildcard/relative attribute paths. E.g., parent, self, sibling, etc. This would solve the problem with ConflictsWith, etc. behaviors where you may not know the full path, but you mean "this other attribute of the same object". We'd just need to be careful with this, as we want to make sure people don't try and send these attribute paths back in diagnostics.
Attempted Solutions
#52
Module version
Use-cases
We're still using
*tftypes.AttributePathall over the place, and that's really verbose to build and can be bothersome to work with, given how close it sticks to the protocol. We should come up with a framework-specific abstraction for attribute paths.Ideally, this would be much less verbose without sacrificing any of the clarity. Perhaps just shortening the names would be enough?
This would also ideally solve problems we've seen in validation, etc. of wanting to be able to specify wildcard/relative attribute paths. E.g., parent, self, sibling, etc. This would solve the problem with
ConflictsWith, etc. behaviors where you may not know the full path, but you mean "this other attribute of the same object". We'd just need to be careful with this, as we want to make sure people don't try and send these attribute paths back in diagnostics.Attempted Solutions
#52