But Python already has a reflection system that allows doing this; people can use the dict of a filter and extract the docstrings of properties if they need to. If need be, we could let each filter define a static list of property strings that people can use to find out which properties are actually settable at runtime.
For now, though, I think this is a non-essential feature, and I don’t think this should be a target for 1.9. We can always think about such a thing later without breaking backward compatibility.
What do these metadata classes do, exactly?
There should be two places to set a filter’s properties: (1) at the Filter itself, which doesn’t need to check for its own existence, and (2) via the CommonFilters interface. In the latter case, we don’t really need to worry about making a clean and efficient solution.
I’m not sure what you mean by a “hybrid type” parameter. If something requires code generation, there’s no point in setting it via setShaderInput.
We can solve this problem elegantly by deferring the reconfigure. Instead of having the setters on a Filter call reconfigure() whenever a property is changed, it should call self.markDirty(), which sets some flags or adds itself to a set needing configure. Then, at the end of a frame (a task with a high sort value?), we go through the list of filters needing to be reconfigured and reconfigure them as appropriate.
I think the new approach should be to let the user deal with it. He creates a filter, and is himself responsible for only adding that filter instance once (or face the consequences), without having FilterPipeline second-guess a decision to add a same-type filter twice.
As for CommonFilters, I think we can just do it like this:
class CommonFilters(object):
def __init__(self):
self.volumetricLighting = None
def setVolumetricLighting(self, setting1):
if self.volumetricLighting is None:
self.volumetricLighting = VolumetricLighting()
self.addFilterInstance(self.volumetricLighting)
self.volumetricLighting.setting1 = setting1
def delVolumetricLighting(self):
if self.volumetricLighting is not None:
self.removeFilter(self.volumetricLighting)
self.volumetricLighting = None
That’s cool. Let’s first focus on getting the framework done, though, before we add all the different filters, though we can of course still regard those filters as a case study to see how flexible the framework truly is.
