Time for std.reflection

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sat Jul 21 17:21:30 PDT 2012


On 7/21/12 8:16 PM, Kapps wrote:
> I agree with most things proposed, however I am not a fan of the idea of
> mixing in runtime reflection info. Many times, you want reflection info
> from a type that is not your own, and thus I believe reflection should
> be generated by specifying a type. More importantly, a method should
> exist for recursively generating reflection info.

I confess I have trouble understanding each of the sentences above.

> Also, I'd like to see a hierarchal approach to reflection data. The main
> advantage to std.reflection would be being able to use it at run-time,
> at which point we can't simply rely on templates, and instead if we want
> to store something we must rely on a base type.

At no place in the proposed approach is the use of templates required or 
needed.

> I think the best
> approach would be a hierarchal system where all reflection data derives
> from MemberInfo. My ideal API would like something like:
> https://workflowy.com/shared/62d4f791-e397-a86d-c018-09eab98b9927/

I cringed at

MemberType -> { Module, Type, Field, Method, Parameter }

I was hoping to get away from slapping tagging on types just for the 
sake of using inheritance.


Andrei


More information about the Digitalmars-d mailing list