On 2011-02-08 05:54, Robert Jacques wrote:
On Sat, 05 Feb 2011 13:14:42 -0500, Jacob Carlborg <d...@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
