I’ve been thinking about delegates and IronRuby.
After playing around with trying to work with a delegate in Ruby (procs,
lambdas and god-knows-what) I’ve come to the conclusion that delegates
have to be supported in a more fundamental way than trying to make a
block work as a delegate.
First off, I think IR has to support adding and removing delegates via
‘+=’ and ‘-=’. That’s how every other .NET language does it (IronPython
included). It doesn’t seem right to use ‘<<’ because there isn’t an
equivalent ‘>>’ (though I suppose you could define one). Anyway, you
have to be able to remove a delegate as well as add one.
Secondly, if you look at the way C# and VB address delegates, they use
syntactic kludges to get round the fact that delegates are function
pointers and are not to be invoked directly. C# uses the method name
with no parentheses and VB uses AddressOf. There isn’t really an
equivalent of a function pointer in Ruby. The most natural way of doing
this, I guess is to use a symbol:
x += EventHandler.new (:y)
However, this doesn’t seem right because a) it won’t run and b) a symbol
isn’t a function pointer. So possibly a better way might be to create a
new class ‘RubyDelegate’ (deriving from Delegate/MulticastDelegate)
which takes the object and method name (or symbol) and returns a real
.NET CLR delegate:
x += EventHandler(RubyDelegate.new (self, “y”))
x += RubyDelegate.new (self, “y”)
Third: I notice that all the other languages (C# and VB at any rate, I
can’t speak for things like F#) futz around with special delegate
keywords to help as well as fooling around with the invokation syntax.
Fourth: Delegates are plumbed into .NET at a pretty deep level. Most
people, most of the time, don’t see them. But they are there - and I’ve
used them quite a bit in communication systems. It seems to me that you
have to recogize them in IronRuby at a similarly primitive level and not
try to pretend that a delegate is equivalent to a block.
A delegate is a function pointer. A block isn’t.