XML: Manage Command handlers as a function dictionary (WIP)

[uliska]

This is a suggestion for an approach to handle the situation described in #117.

What do you think, should I continue laong these lines?

[PeterBjuhr]

Are there any plans to expand this to more categories besides commands?

[uliska]

I think so, once I'm more familiar with it there will probably more of that.

[PeterBjuhr]

There are of course other examples of multiple elif statements. But I'm not yet convinced that this is helpful as a general restructuring. The goal should be to make it easier to add new functionality and to maintain the existing code.

[uliska]

I haven't looked again yet at the code of this PR concretely, but I came across the issue when looking in other corners. I'm not convinced that my suggestion is the best implementation because it may seem to add some level of complexity that is contrary to the goal of making maintenance and development easier. But I'm now even more convinced that it would be good to have a dictionary based infrastructure for a number of things to replace the elif chains.

One example is the End() function that provides endings for a number of different elements.
Another example I came across is Set(). I would like to start supporting specific context properties. This would also require handlers for each supported property.

Somehow I have the feeling that it would be the most natural approach to not use the token as the dictionary key but the element's class, and then instantiate an object of a corresponding class, which would handle the request. Such a could be maintained in its own file, so there's less penalty for implementing lots of special cases (e.g. context properties, element types to be ended ...). Maybe it would even make sense to make this subclasses of the classes in ly.music.items?

However, this is more a random musing than a concrete suggestion. Maybe this won't work because there is no really common interface (i.e. does this need arguments or not, how many, etc).

OTOH I'm thinking if this couldn't be a way to provide an opportunity for people to support their \userCommands. A base path could be passed as an argument, and if there is a certain file it will be included ... No idea if that would work, but it could prove very helpful.

[uliska]

Am 10. Mai 2018 20:25:31 MESZ schrieb Peter Bjuhr <[email protected]>:

PeterBjuhr commented on this pull request. > @@ -91,25 +91,34 @@ def __init__(self): self.phrslurnr = 0 self.mark = False self.pickup = False + self.handlers = {} + self.set_command_handlers() + + def get_handler(self, category, element): + """Return a handler function of a given category, for a given element, + retrieved from the self.handlers dictionary. + For example: self.get_handler['Command']['\\rest'] + If a handler for the given element is not defined, return None.""" + return self.handlers[category].get(element, None) There are of course other examples of multiple `elif` statements. But I'm not yet convinced that this is helpful as a general restructuring. The goal should be to make it easier to add new functionality and to maintain the existing code.

I'll have another look at the code.

…

-- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.