April 18, 2012
On Wed, 18 Apr 2012 14:37:11 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/18/2012 10:20 AM, Steven Schveighoffer wrote:
>> On Wed, 18 Apr 2012 09:59:10 -0400, Jacob Carlborg <doob@me.com> wrote:
>>
>>> On 2012-04-18 03:11, Nick Sabalausky wrote:
>>>> Can't you just query compile-time information to see what classes inherit
>>>> from Base? Then you could just try downcasting to them.
>>>
>>> Is that possible?
>>
>> No. Not from within a template that doesn't know about those classes (which
>> presumably your serialization function is).
>>
>> -Steve
>
> You can get a list of classes in the executable at runtime from:
>
>          foreach (m; ModuleInfo)
>          {
>            if (m)
>              //writefln("module %s, %d", m.name, m.localClasses.length);
>              foreach (c; m.localClasses)
>              {
>                  writefln("\tclass %s", c.name);
>              }
>          }

The question was, can you get this information at compile time.

-Steve
April 18, 2012
On 4/18/2012 11:53 AM, Steven Schveighoffer wrote:
> The question was, can you get this information at compile time.

You cannot get a list of all classes in the program at compile time. For the reason that the compiler doesn't know this information.

April 18, 2012
On 2012-04-18 20:37, Walter Bright wrote:

> You can get a list of classes in the executable at runtime from:
>
> foreach (m; ModuleInfo)
> {
> if (m)
> //writefln("module %s, %d", m.name, m.localClasses.length);
> foreach (c; m.localClasses)
> {
> writefln("\tclass %s", c.name);
> }
> }

Yeah, and then we're back at the original case: we need runtime reflection. We need to be able to iterate the fields of a class and get/set the values of the fields.

-- 
/Jacob Carlborg
April 18, 2012
On Wed, 18 Apr 2012 14:41:30 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/18/2012 1:19 AM, Walter Bright wrote:
>> On 4/16/2012 1:54 PM, Steven Schveighoffer wrote:
>>> 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?"
>>
>>
>> Not a bad idea.
>
> Done.
>
> I think it is a worthwhile idea because it leaves the door open for all kinds of information to be generated for types, without needing to modify the compiler at all.
>
> Also incorporated Jacob's suggestion to make it a property.

I see, looks good!

One interesting question -- which template is instantiated by the compiler, the one in object.di or the one in object_.d?  It seems they are not identical...

Another interesting question, in what context does the RTInfo(T) template get instantiated?  In other words, if you needed more helper templates for GC purposes for instance, what file would have to include that, object.di, object_.d, or some other module?

-Steve
April 18, 2012
On 4/18/2012 1:32 PM, Steven Schveighoffer wrote:
> One interesting question -- which template is instantiated by the compiler, the
> one in object.di or the one in object_.d? It seems they are not identical...

object.di. The compiler does not know about object_.d.

The template should be identical.

> Another interesting question, in what context does the RTInfo(T) template get
> instantiated? In other words, if you needed more helper templates for GC
> purposes for instance, what file would have to include that, object.di,
> object_.d, or some other module?

object.di

April 19, 2012
Le 16/04/2012 04:24, Walter Bright a écrit :
> 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.
>
> Some observations:
>
> 1. if there are no pointers in the allocated data, the GCInfo(T) should
> be null. This enables a fast static check with no indirection for this
> most common case.
>
> 2. closure memory is allocated by calling _d_allocmemory. For now, it
> should just use the old conservative mark/sweep. Later, I can add a
> GCInfo(T) for it.
>
> 3. Many types will follow similar patterns:
>
> ptr .. int .. ptr .. int
>
> ptr .. ptr
>
> int .. ptr
>
> I suggest that specializations exist for these to avoid generating
> innumerable identical data structures or functions. In fact, if they are
> named with names like:
> scanpipi()
> scanpp()
> scanip()
>
> then the linker will automatically remove duplicates.
>
> 4. Stack scanning remains imprecise, and should use the usual
> conservative method.
>
> 5. The "has pointers" bit array can, of course, be eliminated.
>
> 6. I suggest the GCInfo pointer be stored at the end of the allocated
> block, as then it won't affect the alignment of the allocated data.
>
> Release the hounds!

BTW, what about the capability to extends the bahavior for a given type. I'm thinking about XOR linked list for instance.
1 2 3 4 5 6 7 8 9
Next ›   Last »