Proxying Feature to allow per instance customization

[MatthieuDartiailh]

The idea is to allow the user to modify how a Feature works at runtime for a single instance. Both Lantz and Eapii allowed to do so, but I am not sure what are the real use cases. My question is should have that in our library ?

[hgrecco]

The use case is customization of certain properties based on the device itself. Use cases:

1. A driver class for many devices. You have a family of devices with the same command set but different capabilities in their Features (e.g. current limits, DAQ channels, etc). You could have a single class that upon instantiation reads the channel
2. Devices with configurable settings. A device in which the current limit can be set. The you would like to change limits in the current Feature only for a given instance.
3. Devices with introspectable capabilities. During initialize you query the limits of a given feature and set that accordingly.

In 1 you can use subclasses, but 2 and 3 requires per instance configuration.

[MatthieuDartiailh]

10 proposes an alternative way of doing 2 and 3 which does not require to have that kind of proxying. This kind of proxying is rather meant for people unhappy with how the driver is coded, wants to bypass some checks in a particular application, or want to do some testing. It could also be used for adding an observer pattern.

[MatthieuDartiailh]

Closing re-open if necessary but I do not think we really need that feature.