Open danielballan opened 5 years ago
Good summary of the discussion, @danielballan.
The only thing that sticks out that we didn't really discuss is the difference between the classmethod
walk and the instancemethod
walk - and I'm assuming the proposed walk_flag
solution would only apply to the latter.
I personally think there's value in retaining the ability to introspect devices prior to instantiation. Were this to extend to the hypothetical TangoSignal
, there would have to be a flag that indicated dynamic_structure
as the flags could not be determined prior to connecting. And the dynamically-generated proxy components allowing access to that structure would not yet exist.
Agreed. Dumping the git grep
output above without comment was slapdash. The classmethods
seem fine as is to me.
Should we get a better label on this issue?
The addition of the
walk_*
methods into ophyd:[edited to remove classmethods]
prompted a long-running discussion about how different the Device and Signal abstraction in ophyd are and in what ways we should expose those differences. In an in-person discussion between @klauer, @tacaswell, and me, we found this consensus:
Examples:
In recognition of this, we proposed to add one new
IntFlag
to all Signal and Device classes that denotes whether they have structure and whether they are network leaf nodes. Thewalk_*
methods (which have not yet been in any ophyd release) would be removed and replaced by one method,walk(flag_mask, depth)
.