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.
