Time for std.reflection

[Philippe Sigaud]

On Sat, Jul 21, 2012 at 11:44 PM, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:

Nice!

> class ModuleInfo {
> @property:
>     string name();
>     ImportInfo[] imports();
>     DataInfo[] data();
>     FunctionInfo[] functions();
>     ClassInfo[] classes();
>     StructInfo[] structs(); // includes unions
>     TemplateInfo[] templates();
>     EnumInfo[] enums();
>     bool hasStaticCtor(), hasStaticDtor(),
>       hasSharedCtor(), hasSharedDtor();
> }

A few questions:

1) About templates, would class/struct/function templates be in there?
As in:

class Foo(T,U) { ... }
=>
class TemplateInfo {
@property:
    string name();
    FunctionInfo[] functions();
    ClassInfo[] classes();
    TemplateInfo[] templates(); // Yes, templates in templates are
possible, and so on, recursively
...
}

2) Why classes, as opposed to structs? Would inheritance/hierarchies
play a role there? Or reference semantics?
Note that between structs, classes, templates and modules there is a
lot of redundancy. A possibility could be to have an AggregateInfo
base class.

3) For a class, a (to my eyes) standard request would be to get the
parents chain, up to Object. Could that be added in ClassInfo, or as
an external free function? (edit: scratch that, you're talking about
lazy gathering below).

4) How would that allows queries like "Here is class C, give me all
its available subclasses."? Hmm, wait, I get it: extract classes from
the module, and recursively from imported modules. From these classes,
extract the parent classes and so on, until the search ranged over the
whole inheritance tree. I guess inheritance info could be standard
enough for std.reflection to provide such a search.

5) The compiler can emit JSON output giving a partial view of the same
information. As a long-term goal, I suggest these infos should be
compatible somehow. The JSON output should be enriched, and we should
ascertain that using std.json to read this kind of
automatically-generated information should give std.reflection infos
back.

6) Is really all the necessary info available through std.traits and
__traits? Imported modules and their subtilities (renamed functions,
etc) seem out of reach, no?

7) I know your examples are not complete, but don't forget aliases and
symbols, and module-level values. Since these can be of any type, I'm
not sure how they are managed in your scheme. I mean, you cannot have
IntInfo[], DoubleInfo[], ...

8) (more a remark than a question) To me, it's another example of a
tree-like structure. I humbly suggest we get a std.tree somewhere, to
manipulate generic n-ary trees: mapping on trees, searching
(extracting elements or whole subtrees), folding trees, etc. That is,
a module that deals with trees/graphs not so much as containers, but
as a way to represent the relationships between elements. I'm not sure
I'm so clear here, but ideally std.json, std.xml, std.reflection and
probably a few others should use it as a low-level basis.
Btw, I have tree / trees algo (including depth-first / breadth-first
ranges) / graph / graph algo (strongly connected components, search in
graphs, ...) on github, but it's code that predate std.container and
is in limbo, pending std.allocator.


Philippe