On 2012-04-16 18:37, Alex Rønne Petersen wrote:

> The point is that without built-in runtime reflection, reflection is
> only available for select classes that the programmer specifically asks
> to have RTTI for. This is useless. It doesn't enable discovery-based
> reflection at all, which is what makes runtime reflection in C#, Java,
> ... so useful.
>

What he said.

-- 
/Jacob Carlborg

On 04/16/2012 08:42 PM, Jacob Carlborg wrote:
> On 2012-04-16 18:53, Walter Bright wrote:
>> On 4/16/2012 9:40 AM, Jacob Carlborg wrote:
>>> Regardless of how the runtime reflection is generated, by a library or
>>> the
>>> compiler, it needs to be available to all types.
>>
>> Why?
>>
>> (I can see the point for a dynamic language, but not a static one.)
>
> The standard example that comes back is serialization. That can be done
> without support for runtime reflection but not as good as with the
> support. As far as I know it's impossible to serialize through a base
> class reference without registering the subtype with the serializer, if
> runtime reflection isn't available.
>

This could be fixed by introducing a simple language feature that allows a supertype to specify mixin templates that are 'inherited' by all subtypes.

Eg:

interface ISerializable {
    ubyte[] serialize();

    super mixin Serialize;
}

class A: ISerializable {
    int x;
    int y;
}

class B: A{
    A foo;
    @nonserialized B cache;
}

Would be lowered to:

interface ISerializable {
    ubyte[] serialize();

    mixin Serialize;
}

class A: ISerializable {
    int x;
    int y;

    mixin Serialize;
}

class B: A{
    A foo;
    @nonserialized B cache;

    mixin Serialize;
}

This way, all subclasses automatically register themselves.

I think this would be very useful in general. I often do this manually.

On 4/16/2012 10:00 AM, deadalnix wrote:
> The point was that putting this into object.d isn't, IMO, the best option to
> provide such a mecanism.

I don't know of a better way to do it, nor do I think it matters if it is in object.d or someothername.d.

On 4/16/2012 11:02 AM, Sean Kelly wrote:
> On Apr 16, 2012, at 2:25 AM, Walter Bright wrote:
>> It's never going to be easy for anyone to just write their own GC,
>> especially one that works better than one a lot of people have spent a lot
>> of time on.
>
> What I've been going for is to have all functionality that requires knowledge
> of code generation, (most) platform specifics, etc, live in the compiler
> runtime portion of Druntime (i.e. in the "rt" package).  This is all stuff
> that the compiler writer knows by necessity, and the GC writer shouldn't be
> required to know it as well.
>
> As for pointer maps, I think it's reasonable to establish a format that these
> will be made available to the GC, and for them to come from elsewhere in the
> runtime.  I realize that different GC implementations may prefer different
> formats, but hopefully we can settle on one that's pretty generally usable
> and efficient.  I'd really rather avoid expecting GC writers to know how to
> meta-process D types to statically generate this themselves.  Moving this
> into the GC would also eliminate the possibility of having the GC chosen at
> link-time, which is something that's currently still an option.

Either the compiler has to generate the marking stuff, meaning that no user designed GC is very practical, or it has to be generated at compile time with a template, where a user designed GC can experiment with a much wider range of possibilities without needing compiler modifications.

Also, budding GC implementers will have an existing meta-processing code example which will go a long way towards helping get up to speed.

Building a GC is a fairly advanced programming project. I don't think it's unreasonable to expect them to be pretty familiar with how D works.

Switching GCs at link time will only be possible if the GCInfo data is identical between them.

On 4/16/2012 10:08 AM, H. S. Teoh wrote:
> On Mon, Apr 16, 2012 at 09:53:34AM -0700, Walter Bright wrote:
>> On 4/16/2012 9:40 AM, Jacob Carlborg wrote:
>>> Regardless of how the runtime reflection is generated, by a library or the
>>> compiler, it needs to be available to all types.
>>
>> Why?
>>
>> (I can see the point for a dynamic language, but not a static one.)
> [...]
>
> Perhaps for dynamic loading of class objects?

Yes, and then the designer of those class objects will know which ones are to be discoverable.

On 4/16/2012 11:42 AM, Jacob Carlborg wrote:
> On 2012-04-16 18:53, Walter Bright wrote:
>> On 4/16/2012 9:40 AM, Jacob Carlborg wrote:
>>> Regardless of how the runtime reflection is generated, by a library or
>>> the
>>> compiler, it needs to be available to all types.
>>
>> Why?
>>
>> (I can see the point for a dynamic language, but not a static one.)
>
> The standard example that comes back is serialization. That can be done without
> support for runtime reflection but not as good as with the support. As far as I
> know it's impossible to serialize through a base class reference without
> registering the subtype with the serializer, if runtime reflection isn't available.
>

Serialization does NOT need to deal with all types, only the types that are to be serialized.

On Sun, 15 Apr 2012 22:24:56 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> Just checked it in. Of course, it doesn't actually do precise GC, it is just thrown over the wall for the library devs who are itching to get started on it.
>
> I added a getGCInfo() method to TypeInfo that returns an immutable(void)*. This pointer can be anything - a pointer to data, to code, whatever, that implements whatever the GC might need to do precise collections. The value is generated by the template GCInfo(T) in object.d.

I feel this actually can be more generic.  Can we change this to a more generic term?  For example getRTInfo (short for get runtime info) and RTInfo(T)?

Here is my thought:  the GC is not the only entity that might be interested in permanently storing compile-time info for use at runtime.  Yes, the GC could use this (perhaps exclusively), but this actually works as a fairly good hook to generate RTTI necessary to do reflection.

Previously, one had to either parse the object file or make multiple passes through the compiler to generate the info and then include it.  With this template solution, the compiler generates the info using the template and then stores it in TypeInfo.

But we need to change the name early on to avoid conflicts.  I don't think a more generic name would be inappropriate, even if the GC is the only client at first.

-Steve

On Mon, 16 Apr 2012 16:52:54 -0400, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> But we need to change the name early on to avoid conflicts.  I don't think a more generic name would be inappropriate, even if the GC is the only client at first.

Should have said "But we need to change the name early on to avoid confusion later", i.e. "why is this GCInfo template generating reflection info that the GC doesn't use?"

-Steve

On 04/16/2012 10:51 PM, Walter Bright wrote:
> On 4/16/2012 11:42 AM, Jacob Carlborg wrote:
>> On 2012-04-16 18:53, Walter Bright wrote:
>>> On 4/16/2012 9:40 AM, Jacob Carlborg wrote:
>>>> Regardless of how the runtime reflection is generated, by a library or
>>>> the
>>>> compiler, it needs to be available to all types.
>>>
>>> Why?
>>>
>>> (I can see the point for a dynamic language, but not a static one.)
>>
>> The standard example that comes back is serialization. That can be
>> done without
>> support for runtime reflection but not as good as with the support. As
>> far as I
>> know it's impossible to serialize through a base class reference without
>> registering the subtype with the serializer, if runtime reflection
>> isn't available.
>>
>
> Serialization does NOT need to deal with all types, only the types that
> are to be serialized.

That is certainly true. Full runtime reflection is a sufficient, but not a necessary solution.

The issue to be solved is that it is inconvenient and possibly error prone to manually annotate all types that need specialized runtime type info. Eg. If a class subclasses a serializable class, then by default the subclass should be fully serializable without further action.

On 4/16/12 1:31 PM, Alex Rønne Petersen wrote:
> I think we can safely settle on bitmaps for this. Most real world GCs
> use this kind of strategy.

This is a valid argument, but I should say it's very much worth exploring techniques enabled by D specifically. Many unique and superior D idioms would not have existed if we played it safe and did things like everybody else did.

Andrei