Overwriting parameters in inherited instruments

[AdriaanRol]

Currently parameters are added to an instrument in the init. Once a parameter is added it is not possible to overwrite this by using another add_parameter command. When inheriting an instrument you generally want to overwrite inherited functions as well as some parameters. This is currently not possible.

The current workaround would be to overwrite the entire init and copy paste all the add_parameter commands that were in the parent class. I think it makes sens to run super().init(...) and then only overwrite those parameters that are overwritten.

[alexcjohnson]

Three options come to mind:

1. already possible: call del self.parameters['snazzy'] before self.add_parameter('snazzy', ...)
2. we could add a keyword to add_parameter that enables overwriting
3. to avoid even creating such parameters in the first place... this is a little hacky, but you could call super().__init__ after the new params with a pattern like:

def __init__(self, ...):
    # first add the overridden parameters
    self.add_parameter('override1', ...)
    self.add_parameter('override2', ...)
    ...

    # tell add_parameter() to not raise on overrides, just return without adding
    self.ignore_override_errors = True
    super().__init__(...)
    # turn off this behavior afterward
    self.ignore_override_errors = False

we could even get fancy and make this a context manager so you can't forget to clean up:

with self.ignore_override_errors:
    super().__init__(...)

[AdriaanRol]

@alexcjohnson
I like "the with self.ignore_override_errors" option, however I would make it a private function.

[giulioungaretti]

@AdriaanRol can you provide some examples where you would want to do this ?

[MerlinSmiles]

@giulioungaretti you could have a base awesomeness instrument, and have special drivers for models or versions that have a slightly different commandset or extended functionality or something like that.

[giulioungaretti]

@MerlinSmiles fair point !

[giulioungaretti]

So the proposed solution is to have an explicit overwrite_parameter function.
@AdriaanRol and @MerlinSmiles what you think ?

[MerlinSmiles]

@giulioungaretti would it break anything to be able to overwrite existing ones by default?
One might of course break something by doing so...

[AdriaanRol]

I would propose as an argument in add_parameter, not a special function.
The current trick @alexcjohnson proposed based on del self.parameters['parameter_name'] does the trick but it is hard to gaurantee that all traces get removed if we at a later stage decide to change the functionality.

[giulioungaretti]

I think it make more sense be explicit and avoid confusion. In this way you
will be warned both if you overwrite when adding and vice versa.
On Wed, 1 Jun 2016 at 14:19, MerlinSmiles notifications@github.com wrote:

@giulioungaretti https://github.com/giulioungaretti would it break
anything to be able to overwrite existing ones bu default?
One might of course break something by doing so...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
qdev-dk-archive#32 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ACkcNzOExni8ynUAWYIXnkegF_9aCBIrks5qHXi_gaJpZM4HZLTb
.

[giulioungaretti]

@AdriaanRol not sure what you mean with traces.
It's in general harder to reason about parameters (especially if they have default values, as it would be in this case) when refactoring.

[giulioungaretti]

@AdriaanRol how about implementing as you proposed an add_praemter(...., overwrite=False) ?

[jenshnielsen]

This is now possible via #3125