Heh, not entirely, the issue is that the beam files are not always available (whether in a tar file or baked into a single core file, they might not exist).
I’d like to make a macro that generates a file of all known beam files that fulfill the requirements at compile-time to hard-code in such a list, problem is that then prevents dynamically adding beam files later (think plugins to a website) without hard specifying the name (and if you do that anyway then this is not of much use).
There are just too many unhandled cases is the problem…
I don’t think I have it on any of my public repo’s, it is actually just a single file (PluginEx/plugin_ex.ex, adapted for an old erlang version I made almost a decade ago) that I just copy around from project to project. I know its limitations and I get a sick pit in my stomach every time I use it as I know that then prevents this project from working in more embedded areas. ^.^
It is the same use-case, but the problem is just that this method of our implementations is entirely broken in many important case. What needs to be made is a more generic plugin system with perhaps a registration area, but the issue is no way to know if a module implements something without it being loaded, and it may be impossible to pre-load it if the names are not known in some other way. I never really came up with a great idea to the overall problem without forcing every-single-plugin to become registered into the supervision tree some-how, even if it is just some simple callbacks, and even then you have to list the application in the startup file anyway, which is still registering a static name somewhere, which again just defeats the purpose of dynamic lookup. ^.^
