another cool RTInfo trick - i want in runtime

[Adam D. Ruppe]

On Thursday, 16 January 2014 at 20:13:29 UTC, Jacob Carlborg 
wrote:
> Does this only work once? Say I have two libraries that use 
> this technique, would that work?

No, then you'd get complaints about the module being defined in 
two files. This would be a once-per-project thing.

Libraries however could provide helper functions with 
instructions for the user to call them in their project file. For 
example

module my.serialization;
mixin template SerializationAdditionToTypeInfo(T) {
     Whatever serialize() { ..... }
}

and then the user would open up their magic file

module core.config; // BTW this name is just because it was on my 
mind from another discussion with it for enabled features

template CustomRtInfo(T) {
     import my.serialization;
     mixin SerializationAdditionToTypeInfo!T;

     // you can also do other library's stuff here
}



hmmm Vladimir might be right that the custom info thing would be 
better done as a mixin template, then we could throw all this 
right in there and maybe build the whole class. I've gotta try 
it, I'm not sure yet.

> No, not yet. As far as I know, the idea was to use RTInfo to 
> collect and store type info for a precise GC.

Yeah, RTInfo is one of the most potentially cool things that has 
sat untapped for a long time.


> I have had a different idea for a solution to this problem for 
> a while. That is, add a new manifest constant to object.d, 
> called rtInfo. This will act like a UDA. Any template with the 
> object.rtInfo UDA attached to itself will behave just as RTInfo 
> does today.

I think that would need compiler support though and might not 
work as well when compiling two files separately since then part 
of the rtinfo wouldn't get checked. True, here you'd have to 
include the config file each time you compile a file, but at 
least that bit is centralized so easier to manage.

> An idea for storing data in TypeInfo is to create an 
> associative array. The keys would be the fully qualified name 
> of the template, in this case 
> "foo.check_virtual_methods.CheckVirtualMethods". The values 
> would be whatever the template evaluates to. There's one 
> problem with this, the associative array would need to be built 
> at runtime due to separate compilation.

Yeah, I've played with this idea before too, it is definitely 
doable today.