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