Compiler patch for runtime reflection

[Jacob Carlborg]

On 2011-10-25 07:24, Robert Jacques wrote:
> Aren't private methods by definition something people shouldn't be using?

Yes, that's what I mean. But sometimes it CAN be useful.

> :) I don't know myself. I've just heard that the internals of Rails are
> deep, dark and full of non-idiomatic Rudy code.

The parts that I've looked at from Rails are not that special.

>> On
>> the other hand it feels like I'm stretching D's metaprogramming
>> capabilities in my serialization library. That's just because D doesn't
>> have proper reflection.
>
> I've written three serialization libraries and two versions of a runtime
> reflection library; the first one was prior to the string bugs in CTFE
> being fixed and ran DMD out of memory. I found serialization to be
> simple and straight forward. And I found compiler bugs to be a greater
> issue with reflection than any limits in D's capabilities. Indeed, given
> I wrote the same library using two completely different mechanisms,
> gives me great hope for D. So, I don't agree with your assessment, but I
> do understand where you're coming from. A lot of D's metaprogramming
> capabilities are undocumented, and knowing the right tool for the job is
> essential to getting nice, clean code.

For example, getting the name of a instance variable:

T.tupleof[i].stringof[1 + T.stringof.length + 2 .. $];

I wouldn't consider that simple and straight forward. This works for 
both D1 and D2, don't know if D2 has a better way.

Your serialization library only works on public fields? Doesn't sound 
very useful.

> (Just checking, but you do know D has static ctors.)

Yes.

> Actually, you're not supposed to be able to; this is bug 1983.
> http://d.puremagic.com/issues/show_bug.cgi?id=1983 and
> https://github.com/D-Programming-Language/dmd/pull/71

I don't see what that has to do with private, it's about const, as far 
as I can see. I don't see how calling a private method through a 
delegate can be easily solved. I see three solutions:

1. Make it a compile time error to create a delegate from a private 
method. This would not allow to call that method via a delegate in the 
same module, which is possible if you call the method directly.

2. Implement some, most likely, very advanced data flow analysis in the 
compiler to detect when a delegate pointing to a private method escapes 
the module. Results in a compile time error. Will most likely not happen.

3. Make it a runtime error when the delegate is actually called. This 
would probably need some pieces of 2 as well. I don't think the 
community will be happy about adding runtime checks like these.

Oh, BTW the same needs to be done for function pointers as well since 
you can build a delegate out of a function pointer and an object.

>> In Ruby an instance variable is always private. I don't think you can
>> declare a public instance variable, one uses setters/getters for that.
>> In D you can declare both private and public instance variables.
>>
>> In Ruby you can get/set a value of an instance variable using
>> reflection, instance_variable_set/get.
>> In D you can get/set a value of a private instance variable using
>> compile time reflection, i.e. .tupleof.
>
> Yes, but only for source code you control.

You don't need control of the source, you only need the static type. Of 
course an opaque struct won't work.

> Actually, baring bugs in DMD, .tupleof is the only way to access private
> fields and there is _no way_ to access private members; And .tupleof
> only works if you have access to the source code. Furthermore, .tupleof,
> god-send that it is, isn't part of the D spec; unlike .stringof, it
> didn't make it into TDPL nor into the D documentation. D's official
> method of compile-time reflection is __traits. And __traits doesn't
> bypass protection attributes. So precedence would be against
> runtime-reflection having access to private members.

The compiler has .tupleof and it's mentioned in the spec at 
d-programming-language.org: http://d-programming-language.org/struct.html

-- 
/Jacob Carlborg