Compiler patch for runtime reflection

[Robert Jacques]

On Sun, 23 Oct 2011 13:48:03 -0400, Jacob Carlborg <doob at me.com> wrote:
> On 2011-10-23 18:03, Robert Jacques wrote:
>> On Sun, 23 Oct 2011 07:06:42 -0400, Timon Gehr <timon.gehr at gmx.ch> wrote:
>> [snip]
>>> The module can generate RTTI for all types recursively from the starting
>>> point iff that information is statically available. It does not have to
>>> be. A module that comes as .di + static library binary could return a
>>> reference to a private class that has a publicly exported base class.
>>> How would you generate RTTI for a statically invisible class?
>>
>> You're not supposed to be able to. Runtime reflection should only apply
>> to public data members.
>
> It's not enough. Take this for example:
>
> class Foo < ActiveRecord::Base
>      before_save :bar
>
>      private
>
>      def bar
>      end
> end
>
> The above code is an example from Ruby on Rails. The "before_save" call
> sets up a callback, "bar", that will called before saving the model. The
> callback method will be called using reflection.

Using a short, cryptic stub from another programming language is not an effective communication tool. Case in point: all I understand is that something is returning a delegate to something, and reflection never enters the picture.

But, for sake of argument, let me assume that ActiveRecord needs to reflect Foo for rails to work (i.e. ActiveRecord::Base's ctor reflects this). At a very fundamental level, this isn't an argument for or against RTTI in D; in D you'd do this with a mixin of some sort. When looking a use cases/features from other languages, always remember to first ask oneself a) how would I do it in D today? b) Is language X's solution 'better, faster, stronger' in some way?

I mean, considering that Ruby is a dynamic language, would bar even be considered private from inside the super-class's ctor? Is Ruby's private even comparable to D's private? Given that Ruby, by design, requires fields to be private and for all external accesses to happen via methods, should we consider a way to violate that contract an example of mis-feature?