Compiler patch for runtime reflection

[foobar]

Robert Jacques Wrote:

> 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.

IMHO, RTTI should be a built-in feature of the language. 
1) You need one global system agreed upon by all clients. Otherwise, you could end up in a situation where a single class has more than a single set of metadata used in several different scenarios. 
2) This information is required anyway in the run-time itself. This is a requirement for an accurate GC.
3) Other tools might use this info as well, debuggers, IDEs, etc.
4) It's with the spirit of D design - make the common/safe case the default. 

As others mentioned, there should be a compiler switch to turn this off. 
E.g. when developing for an embedded system where memory is scarce it makes sense to not generate RTTI. It also makes sense to disable the GC and preallocate the memory.