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