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
Once an instrument is created, there is no straightforward logic to be able to dynamically add or remove callback functions associated with the instrument created. This poses a challenge in scenarios where the instrument is defined at the module level, but the callback functions are dependent on the specific class instances that utilize the instrument.
An instrument is intended to be a singleton, created once with a unique name to ensure consistent data collection and reporting. However, the need for flexibility arises when different class instances require different callback functions to be associated with the same instrument. Since the instrument can only be instantiated once with a given name, it is typically created at the module level. This design choice ensures that the instrument is shared across the application, but it complicates the management of callbacks that are specific to individual classes.
Describe the solution you'd like
Want to be able to manage the callback of a proxy or real instrument within a class to be able to get the data related to the specific class.
Add callback to instrument and be able to see the changes on the fly
udc.add_callback(_instrument_callback)
udc._callbacks=[_instrument_callback]
Remove callback to instrument and be able to see the changes on the fly
udc.remove_callback(_instrument_callback)
udc._callbacks = []
Describe alternatives you've considered
Creating a custom class that directly manipulates the private variables of the instrument to manage callbacks. It breaks the encapsulation principle, making the codebase more susceptible to error if the internal implementation of the instrument changes in future updates.
class ObservableInstrument:
def __init__(self, inst):
self._inst = inst
if not self._inst._callbacks:
self._inst._callbacks = []
@property
def instrument(self):
return self._inst._real_instrument or self._inst
def add_callback(self, cb) -> None:
self.instrument._callbacks.append(cb)
def remove_callback(self, cb) -> None:
self.instrument._callbacks.remove(cb)
Additional Context
No response
Would you like to implement a fix?
None
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem?
Once an instrument is created, there is no straightforward logic to be able to dynamically add or remove callback functions associated with the instrument created. This poses a challenge in scenarios where the instrument is defined at the module level, but the callback functions are dependent on the specific class instances that utilize the instrument.
An instrument is intended to be a singleton, created once with a unique name to ensure consistent data collection and reporting. However, the need for flexibility arises when different class instances require different callback functions to be associated with the same instrument. Since the instrument can only be instantiated once with a given name, it is typically created at the module level. This design choice ensures that the instrument is shared across the application, but it complicates the management of callbacks that are specific to individual classes.
Describe the solution you'd like
Want to be able to manage the callback of a proxy or real instrument within a class to be able to get the data related to the specific class.
Create instrument without callback
udc._callbacks = []
Add callback to instrument and be able to see the changes on the fly
udc._callbacks=[_instrument_callback]
Remove callback to instrument and be able to see the changes on the fly
udc._callbacks = []
Describe alternatives you've considered
Creating a custom class that directly manipulates the private variables of the instrument to manage callbacks. It breaks the encapsulation principle, making the codebase more susceptible to error if the internal implementation of the instrument changes in future updates.
Additional Context
No response
Would you like to implement a fix?
None
The text was updated successfully, but these errors were encountered: