Time for std.reflection

[Kapps]

On Sunday, 22 July 2012 at 00:21:31 UTC, Andrei Alexandrescu 
wrote:
> 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.

What I meant was that when something requires reflection, it 
generally requires that everything it contains has reflection 
information as well. If using a mixin directly in the module 
itself, when a module does not include this mixin it will never 
get reflection information. This may or may not be desired. 
However it completely prevents many common uses of reflection, 
including serialization. So long as there is any dependency on 
any type or method that does not have reflection info, the entire 
operation would fail. This means that people will either start 
adding reflection to modules that do not need it in fear that 
someone may try to use a member of their module, or too sparsely 
thus making reflection all but unuseable for many common 
situations.

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

What I mean by this is that people rely on the ability to use 
templates as a replacement to inheritance or common interfaces. 
For example, ranges rely on methods existing rather than using an 
interface for a range. With reflection, this isn't ideal. For 
example, if you wanted to get all the fields and properties in a 
module, including nested ones, you'd currently have to get all 
fields, in a module, add those, then get all types in a module, 
then all types in that type, then get all fields from those, etc. 
With a hierarchal approach where MemberInfo has a Children 
property, you'd simply get all children that are a FieldInfo or 
PropertyInfo, and recurse for all returned values that have 
children.

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

Admittedly, the MemberType wouldn't be necessary and I don't see 
as having a huge benefit. In almost all cases you know what you 
want to operate on, inheritance simply makes the API cleaner and 
gives access to common methods more easily.