16956, “bradcray”, “Access CommDiagnostics capabilities through objects?”, “2021-01-15T22:36:30Z”
This week, we discussed whether the CommDiagnostics module would benefit from becoming
more explicitly object-oriented rather than relying on implicit, hidden state. This was generally
received positively, where we were able to imagine a unified interface as proposed in issue #16955
being supported on this object such that you’d write something like:
[where here, and throughout this issue, consider
commDiags to be a placeholder name for
such an object, not the actual proposed name].
There was some question about whether the object on which these routines acted should be:
- a global singleton object
- a singleton object per locale
- an object type that the user could create arbitrary instances of, like
Commentary on each of these options:
using global singleton object: This raised a question about how a global singleton object differs from having standalone functions defined on a module (where I think there was an answer, but I didn’t capture it… TODO: we should fill it in here)
singleton object per locale: It was proposed that this might support the ability to write patterns like:
effectively moving the specification of which locales the measurements should be taken on from the argument list to the
receiver and relying on promotion. There were definitely concerns about this approach as well.
arbitrary object: While there was some interest in making this object’s interface more like
stopwatch, there were also concerns that measuring time passing seemed more independent of who which task was doing the measuring and what else was going on; whereas it might seem surprising to turn on a communication counter and get counts for communications done by your locale (and/or others) which weren’t due to the code you had bracketed with the start/stop calls (?).