Compiler patch for runtime reflection

[Robert Jacques]

On Sat, 22 Oct 2011 07:57:17 -0400, Daniel Gibson <metalcaedes at gmail.com> wrote:
> Am 22.10.2011 05:48, schrieb Robert Jacques:
[snip]
>> What do you mean by their 'parameters'? What about overloads?
>> Attributes? Arguments? Argument attributes?
>>
>
> Primarily arguments. That should help identifying overloads.
> But attributes and argument attributes are needed as well.

But handling overloads is the responsibility of the dispatch system. What would be the use cases for this information?

>>> Something that is close to what Java offers would be great.
>>
>> And what, exactly does JAVA offer? What works? What doesn't work? What's
>> missing?
>
> See
> http://download.oracle.com/javase/6/docs/api/java/lang/Class.html
> You can access constructors (look for one by it's parameters or get all
> of them), the same for methods (methods the class declares and all
> methods, i.e. also inherited ones), implemented interfaces, fields, ...

Thanks, I'll have a look see.

>>> BTW: I don't really see the problem with providing this information
>>> (overhead-wise) - the information needs to be available once per
>>> class/struct, but objects of classes just need one pointer to it (other
>>> types don't even need that because they're not polymorphic and - like
>>> methods of structs - the address of the information is known at
>>> compile-time).
>>
>> 1) Unused information is simply bloat: it increases exe size, slows the
>> exe down and increases the runtime memory footprint.
>
> Yeah, but (mostly) only per class, not per object (besides one pointer
> per object, which shouldn't be that bad and something like this seems is
> already there for the existing typeinfo)

I was assuming the per object bloat was zero. Oh, and I did forget that RTTI increases compile times.