[refacto] DRY for module/extensions method

[crazyiop]

Remove a big chunk of repetitive code.

Note: in the meantime I made the function lookup before calling it. That makes it unnecessary to define all the Module method in all module.

Imho, It makes no sense to force the definition of on_powersave_disable for example for module that have no relation at all with power... A module should be required to define only what it needs.

I pushed only this first to get the discussion going but what can come with this is:

• deletion of the Module class who become useless
• remove all unnecessary method from modules.
• not exactly the same for extensions, but mostly.

[xs5871]

I was thinking about something similar, but instead of checking for the module/extension hooks at runtime, I would have used lists compiled during bootup.
It's true that we can de-duplicate some of the code here. However, I'd prefer methods being actual methods; resolving methods by their string name seems like a misuse of introspection in this case, if not a bit too much of a hack.

[crazyiop]

I just repush with a fix, I got mixed up in my branch..

I'd prefer methods being actual methods;

Not sure of what you are saying here, the module/extensions methods are not touched and the dispatch is still triggered by a method in KMKKeyboard.

seems like a misuse of introspection

This is not a misuse of introspection to me as it is precisely a perfect use case for it. If you don't use getattr/hasattr here, you'll never will. Which kind of imply that you are forbidding yourself to use this basic python functionality for a reason I don't get yet.

Side note: I don't really see how using lists built at boot would allow you to reduce the repetitive code without also refering the function by their name somehow.. You will reduce each KMKKeyboard function I removed by some lines sure, but you will still have the 6 functions differing only by the module method ?

[xs5871]

The precompiled lists would get around repeated runtime checks for immutable data. Doesn't concern introspection.

I was thinking about CPython were you can query function.__name__ instead of hardcoding the name in a string. The difference is that we wouldn't take away the token generation checks from the compiler. As it turns out, Circuitpython doesn't expose the __name__ attribute for functions.

[klardotsh]

I am extremely against this style in any language (my day job is Ruby and I caution against Object.const_get for the same reasons). Harder to follow, encourages footgun behaviours (especially if someone one day later extends this to use dynamically-generated strings), and entirely non-statically-analyzable, which will break anyone's workflows who use Jedi, Python Language Server, Pylance, etc, and also means we would be (I believe) permanently blocked from using a strong type system in these code paths (#205), and if not blocked, the implementation would depend on teaching the type system which strings are valid (at which point we may as well just let it do what it's good at: inspecting what full methods are already defined in a given scope).

[klardotsh]

I think if we want to reduce code here, the trick is probably to add a wrapper method that handles the try/catch stuff and accepts a debug error string, a reference to a method to call, and *args any args that would get passed to the method to be called, probably in that order. Whether it actually improves readability or not, TBD.

[crazyiop]

Ok, I could argue some of those points, but I'm not sure it is worthwhile to spent more time on this as It seems a lost cause given the global opinion.
Thanks for all your input on this.

[xs5871]

I opened a linked issue, because I think the general intent is still worthwile investigating.