Investigate possible removal of "filter" subsystem

[milliams]

In Ganga we have a system called 'filter' (Filters.py) which seem to be a way of injecting code before assignments happen on schema items.

For example, setting

j.postprocessors = FileChecker()

will have a filter (defined in IPostProcessors.py) intercede, and wrap the FileChecker object in a MultiPostProcessor so that doing

type(j.postprocessors)

gives Ganga.GPIDev.Base.Proxy.MultiPostProcessor.

This is work which would make so much more sense being implemented in a standard Python @property 'setter' inside the Job class.

Apart from that, filters seem to provide the possibility of doing

j.backend = 'Remote'

and have it look up the plugin automatically but I'm unsure that anyone uses this in reality.

In summary, I feel that the filter system is too magical and scatters the code that is doing the interception throughout the code base. We need to consider whether the feature is worth the complexity and perhaps consider it for removal in the future.

[rob-c]

In 2 words, Yes Please!

The filters are a lot of complex code for a few minor systems which are in my opinion not worth the overhead. As you mention there are already custom setters widely in use so I think it makes sense to use these functions as it's much clearer what is going on.

I would like to see getting rid of 'on attribute set' hooks over some sane setter methods if possible. This is only really used in a few places and can probably be done correctly in setter methods.

I'm strongly in favor of getting rid of most of the filter code around the Proxy and GangaObject.

We don't strictly lose the last option if we make sure to test string assignment in the same way that we do in the Proxy def _init, there is a mechanism in place to convert the string into applicable objects which isn't being used on assignment atm.

[alexanderrichards]

this is what ive done in the rewrite so it makes sense to me