Store Address
on V2 Target
and pass it to Field
s during validation
#9300
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
With the V2 Target API, by design, fields live independently of targets. This means that they cannot access any of the information from their parent target or be traced back to their original owner. For example,
my_tgt.Get(Compatibility)
will returnCompatibility
as a distinct type.This is an issue during validation of fields. When validating a field, we need to refer to the original owning target to be able to generate a helpful error message that says which target the error comes from.
Beyond generating useful error messages, some
AsyncField
s need to use theAddress
to hydrate, such asSources
.Solution
Change the constructor for
Field
to takeAddress
.However, we don't actually always store an
Address
field on everyField
instance.PrimitiveField
s have no use for theAddress
after they are validated in the constructor. It would be a non-trivial cost in space to store anAddress
on every single field ever encountered. So,PrimitiveField
s use theAddress
during the constructor, and then throw away the value after.In contrast to
PrimitiveField
s,AsyncField
s are validated lazily, so they do need to preserve theAddress
as an attribute.Result
Field validation can now have helpful error messages. We can also now use
Address
forAsyncField
s, which allows us to implementSources
.Remaining followup
In a followup, we will provide standard exception types to make it much easier for field/plugin authors to create high-quality error messages.