Compiler patch for runtime reflection

[Jacob Carlborg]

On 2011-10-23 20:54, Robert Jacques wrote:
> 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.

What's happening is that the class method "before_save" is called with 
the symbol (think string) "bar". Then later ActiveRecord::Base will call 
the method corresponding to the string "bar" using reflection.

In D you would proabably do something like:

class Foo : ActiveRecord.Base
{
     private void bar () {}

     mixin beforeSave!(bar);
}

Now you still won't be able to call "bar" outside "Foo" if "bar" is private.

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

You can think of it like this, just because you haven't come up with a 
reason for calling privte methods using reflection doesn't mean anyone 
else won't come up with a good reason. I tried here to give a reason.

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

There is no constructor involved here. "before_save" is class method 
called when the class "Foo" is loaded.

You can do basically whatever you want with the code in Ruby. You can 
replace an existing method/class in the standard library with your own. 
You can easily add methods to existing classes. It's the programmer that 
is responsible to not mess up things, just as in D where you can cast 
away immutable, shared and do unsafe things with pointers.

-- 
/Jacob Carlborg