On Sunday, 2 June 2013 at 09:33:27 UTC, Benjamin Thaut wrote:
> I think this is a very good idea. The only question is how complete this RTTI should be.

For now, I'm going for just a UDA based thing, so it is almost all opt-in. Though one downside of my idea here is it may be slow, since it pulls info from a list (I'm doing a linear array, but it could be a binary search of AA or something without much difficulty, but my guess is most entries will only be a handful of elements long anyway).

Actually adding members to the rtinfo struct would avoid this cost, but I can't think of any way to do that without modifying object.d for each one.

Perhaps we could have a userRtInfo template that works the same way, but that one is defined in the module that defines the type, instead of in object.d. The module would be responsible for casting the void* in typeinfo (a new method, urtInfo to complement rtInfo) back to the type they defined. I think that would be doable at least.


The other thing I'm pondering is changing TypeInfo to be generated at compile time and include all kinds of functions like std.traits offers. This would only be builtin types, user structs and classes have RTInfo instead, so that limits the size somewhat, but it nevertheless does increase exe size and isn't easy to opt out of, since you'd have to recompile at least part of druntime to do it.

Expanding typeinfo is arguably less useful since if you want that info, you can do it yourself in a template like std.variant, but one use I can see is the D style variadics. Instead of a list of types with code right there, you could just do typeid().is/getNumeric() or whatever.


> The RTInfo template is very usefull for many different tasks, the question is if we shouldn't make the concept more generic so that you can have multiple templates which behave like the RTInfo template. I'm currently also using it for RTTI info see: http://3d.benjamin-thaut.de/?p=25

very cool.

On Sunday, 2 June 2013 at 13:28:28 UTC, Rainer Schuetze wrote:
> and TypeInfo.rtInfo() would then return a pointer to RTInfoData instead of void*. This doesn't make it modifiable from outside object.di, but I have no idea how that could be possible to begin with (without recompiling the runtime library).

I think I have something figured out:

use side:

// i'll use this as a UDA
struct InfoStruct {
        string info;
}

// and this as the template extension
struct MoreRtInfo {
        string amazing;
}

@CustomInfo!(InfoStruct("info struct data")) // UDA style, goes into an array
class RTTest {
       // template style, goes in a special member
        static template userRtInfo(This) {
                static __gshared i = MoreRtInfo("amazingness");
                enum userRtInfo = &i;
        }
}


Retrieve:

        auto info = typeid(RTTest).rtInfo();
        if(info is null)
                throw new Exception("wtf");

        auto urtInfo = info.userRtInfo; // this is from the template..
        if(urtInfo is null)
                write("urtInfo == null\n");
        else {
               // it comes out as a void*, so we have to cast it back.
                auto urt = cast(immutable(MoreRtInfo)*) urtInfo;
                write("cool ",urt.amazing,"\n");
        }

        // and this is fetching the CustomInfo UDA
        auto cd = info.getCustomInfo!InfoStruct;
        if(cd is null) // it returns a InfoStruct*, like AA's in operator
                write("InfoStruct is null\n");
        else
                write(cd.info, "\n");







And the implementation side in object.d:



        struct MoreTypeInfo {
                // other stuff druntime is free to declare
                hash_t hash;
                string stringOf;

                 // holder for the template thing
                immutable(void)* userRtInfo;

                 // holder for the UDA thing
                immutable(CustomTypeInfoExtension)[] customInfo;

                 // helper for the UDA get
                immutable(T)* getCustomInfo(T)() immutable {
                        auto hash = typeid(T); // typehash!T;
                        foreach(ci; customInfo) {
                                if(ci.typeOfData == hash)
                                        return cast(immutable(T)*) ci.data();
                        }
                        return null;
                }
        }


       // instantiates the T.userRtInfo, if possible
        template urtInfo(T) {
                static if (__traits(compiles, { auto a = cast(immutable(void)*) T.userRtInfo!T; }))
                        enum urtInfo = cast(immutable(void)*) T.userRtInfo!T;
                else
                        enum urtInfo = null;
        }


        template RTInfo(T) {
                __gshared static immutable minfo = MoreTypeInfo(
                      // stuff druntime is free to add
                      typehash!T, T.stringof,

                       // the user defined template
                        urtInfo!T,

                       // getting the UDA stuff
                        getCustomInfoInternal!T);
                enum RTInfo = &minfo;
        }

        // finally, helpers in getting the UDAs, I posted this before too

        struct CustomTypeInfoExtension {
                TypeInfo typeOfData;
                // ctfe complained when I tried to just do &static_data
                // so instead this little function helper does it for us
                void* function() data;
        }

        immutable(CustomTypeInfoExtension)[] getCustomInfoInternal(T)() {
                if(__ctfe) {
                        //bool[hash_t] seen;
                        immutable(CustomTypeInfoExtension)[] ext;
                        foreach(attr; __traits(getAttributes, T))
                                static if(is(typeof(attr) == CustomTypeInfoExtension)) {
                                        //auto hash = attr.typeOfData.rtInfo.hash;
                                        //if(hash in seen)
                                                //assert(0, "repeated data");
                                        //seen[hash] = true;
                                        ext ~= cast(immutable) attr;
                                }
                        return ext;
                } else return null;
        }

       // this is the user uses: @CustomInfo!(something)
        template CustomInfo(alias T) {
                __gshared static data = T;
                void* getRaw() { return cast(void*) &data; }
                enum CustomInfo = CustomTypeInfoExtension( typeid(typeof(data))/*typehash!(typeof(data))*/, &getRaw);
        }



> Unfortunately the compiler sometimes doesn't force the generation of RTInfo, but sets the m_rtInfo to 0 or 1 depending on whether the Type contains pointers or not. I always wanted to figure out why that happens...

weird

Am 02.06.2013 15:28, schrieb Rainer Schuetze:
>
>
> On 02.06.2013 11:33, Benjamin Thaut wrote:
>> I think this is a very good idea. The only question is how complete this
>> RTTI should be. This again highly depends on what it will be used for.
>> For some users it might be ok to do a full RTTI, which will increase the
>> executable size significantly. Other users might prefer a minimal RTTI
>> or even no RTTI at all depending on the use case.
>>
>> The RTInfo template is very usefull for many different tasks, the
>> question is if we shouldn't make the concept more generic so that you
>> can have multiple templates which behave like the RTInfo template. I'm
>> currently also using it for RTTI info see:
>> http://3d.benjamin-thaut.de/?p=25
>>
>
> As a number of use cases show up for the RTInfo template (the precise GC
> also uses it), I think a simple approach for not stepping on each other
> toes would be to declare a struct type RTInfoData, and add each
> implementation as a member to this struct (not checked whether this
> actually compiles):
>
> struct RTInfoData
> {
>      immutable(RuntimeReflection)* rr;
>      immutable(thMemberInfo)* th;
>      immutable(PreciseGCData)* gc;
> }
>
> template RTInfo(T)
> {
>      immutable(RTInfoData) data = RTInfoData(genRuntimeReflection!T,
>                                              genMemberInfo!T,
>                                              genGCData!T);
>      enum RTInfo = &data;
> }
>
> and TypeInfo.rtInfo() would then return a pointer to RTInfoData instead
> of void*. This doesn't make it modifiable from outside object.di, but I
> have no idea how that could be possible to begin with (without
> recompiling the runtime library).
>
> Unfortunately the compiler sometimes doesn't force the generation of
> RTInfo, but sets the m_rtInfo to 0 or 1 depending on whether the Type
> contains pointers or not. I always wanted to figure out why that happens...

That is the obvious solution to the problem. Maybe we should get something like this into drutime ASAP so that the RTInfo template remains extendable even if a percise GC is used.

Kind Regards
Benjamin Thaut

On 02.06.2013 17:10, Adam D. Ruppe wrote:
> On Sunday, 2 June 2013 at 13:28:28 UTC, Rainer Schuetze wrote:
>> and TypeInfo.rtInfo() would then return a pointer to RTInfoData
>> instead of void*. This doesn't make it modifiable from outside
>> object.di, but I have no idea how that could be possible to begin with
>> (without recompiling the runtime library).
>
> I think I have something figured out:

Interesting stuff to implement custom type info declared with the class. But type info as needed for the GC has to be generated for every Type without additional annotation or declaration.

Assuming a recompilation of the runtime library, but no modification to the library source, I currently can only imagine having some string import switched to some other file through a different search path. This import would then contain declarations to be mixed into the RTInfoData (or MoreRtInfo in your implementation).

On Thursday, 30 May 2013 at 15:12:57 UTC, Steven Schveighoffer wrote:
> I would like to see the necessary framework for RTInfo to allow expansion WITHOUT having to modify object.d.  I think this can be done, and then it allows anyone to insert whatever they want for RTInfo based on their own needs.


Eureka: http://forum.dlang.org/thread/zgjgfprbkeiapjipldwf@forum.dlang.org#post-fnxfhvhvmhuweyxfricb:40forum.dlang.org

On Fri, 21 Jun 2013 08:43:15 -0400, Adam D. Ruppe <destructionator@gmail.com> wrote:

> On Thursday, 30 May 2013 at 15:12:57 UTC, Steven Schveighoffer wrote:
>> I would like to see the necessary framework for RTInfo to allow expansion WITHOUT having to modify object.d.  I think this can be done, and then it allows anyone to insert whatever they want for RTInfo based on their own needs.
>
>
> Eureka: http://forum.dlang.org/thread/zgjgfprbkeiapjipldwf@forum.dlang.org#post-fnxfhvhvmhuweyxfricb:40forum.dlang.org

Nice :)

-Steve