Dynamic listing/scanning/discovery of "annotated" modules or functions?

[utybo]

One thing that could be very useful is to dynamically list a group of modules or functions.

In Java, there are multiple libraries that can give you a list of classes or methods or "things" that are annotated with a specific Annotation. This allows you to make very flexible systems like plugin systems without having to hard-code where the classes you want are (see below for a more detailed example). I believe this would be a very worthy addition to Golo, as, afaik, you have no way of dynamically doing this at runtime, and all you can do is hard-coding a list of classes, without any "dynamic discovery" system.

I am not sure of how this could be done though -- I'm not even sure if it could be done.

So far in Java all I've seen for detecting annotated classes is :

• Scanning through everything and detecting the annotations at runtime (in the spirit of Reflections)
• Use the Annotation Processing Tool (APT) at compile time to build a list of annotated classes (or classes that implement a specific interface or extend a specific class) in the spirit of ClassIndex, where this list is stored in a service file in META-INF. Unfortunately, APT is a feature of the Java compiler, and not a standalone tool, so it cannot be reused.

A real world example of this would be a program that gives you a list of tools, where each tool has its own module or class. In Java, you can say "all the classes that represent 'tools' have to be annotated with this annotation" and that would be fine when using the libraries -- you would then be able to freely add more tools by adding more annotated classes without the need to touch anything else, which also enables dynamically loading tools from other JARs. In Golo, you have to hardcode the list of all the tool modules, and you won't be able to dynamically load them from other "Golo-JAR"s.

[yloiseau]

Thanks to the Java/Golo integration, you can use standard java reflection features, and third parties libraries should also work. Predefined.fun may be enough in some cases. Some of the (undocumented) features in o.e.golo.runtime package could also be useful.

Annotations introspection on java classes is thus possible. Golo functions and types can not yet be annotated, but the upcoming macros will allow it.

However, for your plug-in use case, keep in mind that since golo is fully dynamic, you can load golo files at runtime. So provided some naming conventions to mitigate the lack of interfaces and annotations, the use case should be easy to implement.

By the way, once the macro feature will be in, I plane to add a facade package to ease meta-programming, both compile time (utils for macro and IR manipulation) and runtime (reflection and dynamic loading and invocation)

[utybo]

Thanks! I will keep an eye out for the macro feature then :)