Points about Function Pointers

I didn't have enough time to really read through loads of blogs and forums about the function pointers proposal but I did read this PDF. It seems to be like a very straight forward thing: basic function pointers, or delegates if you're familiar with dotNet. There are some points I'd like to make regarding the proposal itself, and then some points from my own experience with dotNet's delegates.

• Removing "final" requirement The paper proposes to not use the same "final" requirement for closures, or annonymous methods, the same way it is required when making annonymous classes. Further, the paper suggests to remove this requirement from annonymous classes as well, as it claims it doesn't offer much anyway, and I tend to agree. The "final" requirement seems to make code more readable by preventing weird situations in multithreading code, but these situations could occur if you write bad code anyway. If I'm mistaken here, and surely there are those who would say I am, please correct me.
• Changing the "throws" syntax The proposal suggests using a vertical bar ( | ) to separate between exceptions that might be thrown from a method. The reason they give is sensible, although I don't like the syntax of 'vbar' they suggest. I much prefer removing the ability to define more than one variable of a function pointer instead of changing the throws syntax to something ugly. That's me, though.
• Autoboxing into interfaces It seems like the idea is to autobox an interface into a function pointer. That means, to my understanding, that interfaces with a function that answers a certain function pointer type could be autoboxed to that function pointer type. This would make it easy for API developers to switch from interfaces to function pointers. The example given in the proposal is the Runnable interface, where a function pointer of type void() could be used instead. Usually, that would break code, and this is where the autoboxing option comes to the rescue. I think that's a great idea, at least for a while, to help users of APIs adjust to the changed API. I also think that this sort of autoboxing should generate a warning which would help developers to switch their code to the new semantics.

Regarding my own experience, I have only one (though long) remark: A function pointer should be a single instance. What I mean is, that if the function pointer is of a static method, it should be a singleton instance. If it belongs to a class instance, it should be a single instance in that class instance. More than that, the class instance should have a hard link to that function pointer. The reason for this is coming from the need to somehow contain a weak reference to the function pointer, in order to not keep the instance of the function alive. An example for when this might be useful: Suppose the function pointer is used to trigger events. Suppose the event handler doesn't want to be the instance keeping items alive, and doesn't want to force listeners to unregister when they are disposed. With interfaces, the instance triggering the event could keep a weak reference list of all the interface instances listening to the event (as I've shown in an earlier post). With delegates in dotNet this is impossible - Every delegate passed is a new instance, and two delegates of the same method in the same instance are different objects. That makes such a list impossible as it will always remain empty - The list is the only one refering to that delegate (using a weak reference!), so it will be garbage collected as soon as possible. If it was the same instance for the same method in a class instance and it would have been somehow referenced by the containing instance, this would have been prevented and such a weak reference list could have been made. Also, it would have prevented multiple instantiations of the same pointer. Before I wrap this up, I would just like to mention this other post of mine, discussing delegates in Java.