On Sun, 23 Oct 2011 13:48:03 -0400, Jacob Carlborg <d...@me.com> wrote:
On 2011-10-23 18:03, Robert Jacques wrote:
On Sun, 23 Oct 2011 07:06:42 -0400, Timon Gehr <timon.g...@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?
