You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bit of background: the construct for referencing templates within a pointer is already a bit weird, designed in a way so as to minimize the complexity of each particular ethdebug/format/pointer/collection/* schema. It works by composing a reference collection inside a scope collection:
The expectation for debugger implementations is to aggregate a flat list of all the regions that are generated when observing runtime state; multiple regions of the same name are fine and recognized by the spec for real reasons (e.g. when pointing to all the items in an array, this naïve approach is sufficiently fine).
But if you want to reuse the same template multiple times, in multiple places (like inside a very large struct), this becomes extremely unwieldy.
It seems likely that the schema for these references will need to be expanded to accommodate the renaming of regions, similar to how some code that calls a reusable function gets to name the function's return values. This change will also require updating the reference implementation and its documentation.
The text was updated successfully, but these errors were encountered:
Bit of background: the construct for referencing templates within a pointer is already a bit weird, designed in a way so as to minimize the complexity of each particular ethdebug/format/pointer/collection/* schema. It works by composing a reference collection inside a scope collection:
The expectation for debugger implementations is to aggregate a flat list of all the regions that are generated when observing runtime state; multiple regions of the same name are fine and recognized by the spec for real reasons (e.g. when pointing to all the items in an array, this naïve approach is sufficiently fine).
But if you want to reuse the same template multiple times, in multiple places (like inside a very large struct), this becomes extremely unwieldy.
It seems likely that the schema for these references will need to be expanded to accommodate the renaming of regions, similar to how some code that calls a reusable function gets to name the function's return values. This change will also require updating the reference implementation and its documentation.
The text was updated successfully, but these errors were encountered: