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
