Calling method by name.

[Jacob Carlborg]

On 2011-02-08 05:54, Robert Jacques wrote:
> On Sat, 05 Feb 2011 13:14:42 -0500, Jacob Carlborg <doob at me.com> wrote:
>> On 2011-02-04 05:07, Jonathan M Davis wrote:
> [snip]
>>> Most of the good examples of runtime reflection that I'm aware of
>>> require user-
>>> defined attributes. But there are libraries in Java (and presumably
>>> C#) that do
>>> stuff like allow you to mark your classes with certain attributes
>>> indicating what
>>> type of XML elements that they should be, and then another library
>>> which knows
>>> _nothing_ about your classes is able to serialize them to and from
>>> XML. Another
>>> example would be Hibernate, which does the same sort of stuff only it
>>> deals with
>>> talking to databases. Full-on runtime reflection combined with
>>> user-defined
>>> attributes can do some powerful stuff. However, I do think that
>>> runtime reflection
>>> without user-defined attributes doesn't tend to be anywhere near as
>>> useful. To
>>> really get that sort of stuff working, we'd need D to properly
>>> support both user-
>>> defined attributes and runtime reflection. Both are future
>>> possibilities but
>>> obviously aren't happening any time soon.
>>>
>>> - Jonathan M Davis
>>
>> Ruby seems to get along without any kind of attributes/annotations.
>> But on the other hand you can call a method in a class declaration and
>> this will behave much the same as a attribute.
>>
>> ActiveRecord in Rails is a good example of runtime reflection. Also
>> the Ruby XML library "builder" is a good example of runtime
>> reflection. Maybe not acutally runtime reflection but is uses the
>> "method_missing" method, equivalent to the "opDispatch" method in D,
>> heavily.
>>
>> http://builder.rubyforge.org/
>>
>
> I'm still reading up on Ruby, but so far, there are two major difference
> between serialization in Ruby and in D. First, Ruby isn't a systems
> programming language with pointers/unions/etc, so serializing all
> members of a class is generally okay in Ruby but isn't in D. This is the
> major advantage of annotations: its a fast, simple way of declaring what
> should and shouldn't be serialized. Second, Ruby's support for
> serialization creates a back door around its variable protection
> annotations (i.e. private,package,protected,public). Now, Ruby doesn't
> actually have user defined annotations as far as I can tell, but methods
> are always public and variables are always private. I don't believe that
> a reflection system should bypass encapsulation. The advantage of
> annotations is that they allow you to declare programmer intent and
> possibly separate APIs (ala const(T)) for special purposes.

Ok, lets have a look at how a serialization annotation could look like in D:

class Foo
{
     @NonSerialized int x = 3;
}

Now the same can be done in Ruby, without any special syntax, like this:

class Foo
     @x = 3
     non_serialized :x
end

In the Ruby example "non_serialized" would be a class/static method 
which recives a symbol indicating what field to skip during 
serialization. Actually since Ruby is a dynamically typed language I 
don't have declare "x".

What I'm trying to say is that Ruby doesn't need a special syntax for 
annotations since you can in Ruby do all (most of) the things you can do 
with annotations but with class methods instead.

In general, serialization breaks encapsulation, not just in Ruby. You 
can break encapsulation in D as well using .tupleof and delegates to 
methods.

Ruby just has a different attitude. It allows you to

* Call private methods using "send"
* Add/remove/change methods on existing classes
* Change variables declared as const

It's no like Java which holds your hand all the time. It's the same with 
D, but in a different way. In D there's instead:

* Pointers
* Unions
* malloc/free/delete

-- 
/Jacob Carlborg