Draft: 🗑 ️ deprecate the quiddity creation from the pyQuiddity constructor and ✨ add a quiddities descriptor for pySwitch
should close #100 (closed)
this MR is doing two things, I tried (and failed) to separate concerns:
🗑 ️ deprecation of the quiddity creation from the pyQuiddity constructor
it seems this was my major issue and I took the decision to remove it:
- before:
py_quiddity = switcher.create(kind, nickname, config)
py_quiddity = Quiddity(switcher, kind, nickname, config)
- now:
py_quiddity = switcher.create(kind, nickname, config) assert isinstance(py_quiddity, Quiddity) == True # you can still use the Quiddity constructor but I don't recommend it copy = Quiddity(switcher, py_quiddity.id())
why?
- it reduces the way of creating quiddities for two methods to one
- it could confuse user
- it is more efforts to maintain (this mr is a proof)
- the quiddities have not the responsibilities to instantiate itself in the cpp source
- the py API should be as close as possible to the cpp source in order to avoid frictions like #100 (closed)
- the Quiddity constructor is only used twice in exemple/tests so it doesn't seem a big deal
- this creation in the constructor lead me to a headache because I wanted to instanciate a pyQuiddity object that was already created
- making the pyQuiddity more complex shouldn't the right direction for future maintenance
✨ add a quiddities
descriptor for pySwitch
- I implemented a
get_quiddities
method that returns a list of all quiddities - the quiddities descriptor is a way to get those from a property
- it also allows us to provide extra feature in order to easily query quiddities without extra cpp methods
vid_quids = [quid for switcher.quiddities if quid.kind() is 'videotestsrc']
Edited by Valentin Laurent