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.
