>> One of the tools I want to eventually use the "DMD front end starter kit"
>> for was a program (I've been calling it "deflect") that takes a class
>> source file (say A) and generates a "metadata" class output source (for
>> say MetaA) that can be compiled and linked with A so that code that wants
>> to serialize and deserialize A can ask MetaA to do it. A meta class is a
>> bit like the ClassInfo class but it has more hooks - eg the entire
>> reflection API in Java would be possible. You can ask MetaA for the
>> fields in A, their offsets, their types etc etc.
>> If you are feeling ambitious you can grab the DMD Front End starter kit
>> from http://home.comcast.net/~benhinkle/dmdfe/ and take a crack at it.
>> Note that such a program would do more than support serialization so it
>> might be too much for your particular needs.
>
> I saw dmdfe, but was unsure how to incorporate it, could you give examples, or instructions on how to go about getting at that meta class you talk about? Like I said, I am very new to the C/D paradigm, growing up as a programmer in Java/C#.

The metadata is stored in the parse tree created in memory while reading in the source file. That is what the dmd front end is for. The dmd back end (which Walter has but not dmdfe) takes that tree and generates code and object files. What I'm suggesting is taking that tree and generating source code that would allow D programmers to query and manipulate classes and/or class instances. So there would be alot of work to do just to get to the point of writing the class info to a file much less a D source file that obeys some API. My guess is that given your D experience it would be too much unless you have experience with compiler internals (which I don't).

Ben Hinkle wrote:
>>>One of the tools I want to eventually use the "DMD front end starter kit" for was a program (I've been calling it "deflect") that takes a class source file (say A) and generates a "metadata" class output source (for say MetaA) that can be compiled and linked with A so that code that wants to serialize and deserialize A can ask MetaA to do it. A meta class is a bit like the ClassInfo class but it has more hooks - eg the entire reflection API in Java would be possible. You can ask MetaA for the fields in A, their offsets, their types etc etc.
>>>If you are feeling ambitious you can grab the DMD Front End starter kit from http://home.comcast.net/~benhinkle/dmdfe/ and take a crack at it. Note that such a program would do more than support serialization so it might be too much for your particular needs.
>>
>>I saw dmdfe, but was unsure how to incorporate it, could you give examples, or instructions on how to go about getting at that meta class you talk about? Like I said, I am very new to the C/D paradigm, growing up as a programmer in Java/C#.
> 
> 
> The metadata is stored in the parse tree created in memory while reading in the source file. That is what the dmd front end is for. The dmd back end (which Walter has but not dmdfe) takes that tree and generates code and object files. What I'm suggesting is taking that tree and generating source code that would allow D programmers to query and manipulate classes and/or class instances. So there would be alot of work to do just to get to the point of writing the class info to a file much less a D source file that obeys some API. My guess is that given your D experience it would be too much unless you have experience with compiler internals (which I don't). 
> 
> 

Gonna need more than that. I dont even know what to do with these stubs.  When to they get called, what data is available when they do, etc. etc. I really am a newbie.

Tom S wrote:
> Kyle Furlong wrote:
> 
>> BTW Tom, what does your library actually do? Could you post some sample code?
>>
>> Kyle
> 
> 
> I guess it's not what you are looking for, since the user of my lib has
> to implement a 'describe' function to enable serialization, e.g.:
> 
> #    void describe(Serializer s)
> #    {
> #        super.describe(s);
> #        s.str!(Texture)(diffuseTex);
> #        s.str!(Texture)(lightmapTex);
> #    }
> 
> or
> 
> #    void describe(Serializer s)
> #    {
> #        if (Serializer.SMode.R == s.mode)
> #        {
> #            ISceneNode[] chLst;
> #            s.objArr!(ISceneNode)(chLst);
> #           #            foreach(ISceneNode ch; chLst)
> #                attachChild(ch);
> #               #            delete chLst;
> #        }
> #        else
> #        {
> #            s.objArr!(ISceneNode)(m_children);
> #        }
> #       #        s.arr!(char)(m_name);
> #    }
> 
> or
> 
> #    void describe(Serializer s)
> #    {
> #        s.strArr!(vec3)(vertices);
> #        s.strArr!(vec3)(normals);
> #        s.strArr2!(vec2)(texCoords);
> #        s.strArr!(vec3ub)(colors);
> #        s.arr!(uint)(indices);
> #        s.obj!(Effect)(effect);
> #    }
> 
> And classes have to be registered in a factory:
> 
> #    static this()
> #    {
> #        new factory.type!(DirectionalLight);
> #        new factory.type!(PointLight);
> #    }
> 
> Yet for simple structs it's enough to use a mixin:
> 
> #    mixin Serializer.RawStruct;
> 
> 
> ... and it's capable of serializing whole complicated object hierarchies
> just like this:
> 
> #    ISceneNode level = Pickle!(ISceneNode).read("level.sg");
> 
> #    Pickle!(ISceneNode).read("optimizedLevel.sg").setParent(root);
> 
> Note: Circular referencing classes will serialize just fine, as class instances are serialized just once. But this is only implemented for classes. If you have structs that recursively reference each other, you'd get a nice infinite loop. I didn't need that functionality yet, but it's gonna get there. The API is probably also going to change.
> 
> Anyways, if you want to take a look ( to get some ideas or find out how not to do it ;) ), the sources are here:
> http://codeinsane.info/listDir.spy?viewType=normal&path=code/heresy
> 
> The file is called serializer.d but I've given you a link to a wider code base because serializer.d is dependent on some other modules.
> 

I think that for the meantime I would settle for the functionality you provide? Will you allow others to use your code? Let me know.

Kyle Furlong wrote:
> I think that for the meantime I would settle for the functionality you provide? Will you allow others to use your code? Let me know.

This code is public domain, you're welcome to use it.


-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/