From http://msdn.microsoft.com/library/en-us/dndevqa/html/msdn_andersh.asp, an interview with Anders Hejlsberg, the original architect of Borland's Delphi, regarding some of the work he had done for the "Windows Foundation Classes", part of Microsoft's J++ product, after he jumped ship from Borland.
His work was later adopted into C#. It was also a key point in Sun's complaints about the MS Java implementation, because they introduced a keyword 'delegate' to implement it, as dynamic proxies were not available. Also, as a language feature, MS's delegates could be statically checked against method signatures at compile time. <quote> MSDN: Can you describe the new eventing model in WFC, which uses something you call delegates? Hejlsberg: The technically correct term for delegates is "bound method references." If you think about the ActiveX or JavaBeans eventing models, they both use interfaces for eventing. We use delegates, or bound method references. For example, in the ActiveX or JavaBeans world, if you have a button that wants to fire an event, it does so by defining an interface. Someone has to implement that interface and then give it to the button so the button can call back on that interface, in order to fire events. In the WFC component model, a button essentially has a bound method reference that it calls when you click on the button. You don't have to implement an interface in order to receive the event. You simply have to supply an object and a method and say to the button, "When you're clicked, just call this method on this object." So it's a simpler model. It's also a more flexible model. If you look at how JavaBeans tools today implement eventing, they have a problem. Let's say you have a form that has 100 buttons on it, and you want to have a separate event handler for each button. Now you need to implement this event interface 100 times, but you can't, you can only implement that interface once. You're faced with either having to write 100 adapter classes--that is, little classes that each implement the button interface and then forward it to the particular event handler--or you have to write one handler that has a gigantic switch statement that switches on the sender of the event. You're either trading a lot of space away, because classes are fairly big in footprint, or you're trading speed away. But with the WFC delegate model, you're not trading anything away. The other thing that's interesting about delegates--and particularly how we implemented delegates --is that we can do automatic multicasting of events. A control that fires an event sees essentially one bound method reference, one delegate that it calls to. That delegate will (underneath the hood) potentially call many receivers of the event. This all happens automatically, and with great efficiency. Another thing that's interesting about delegates is they allow you to do many-to-one mapping of event handlers. Because you're just referencing methods, you can have a button click and a menu click both go to the same event handler. You don't have to write these things that forward the call to a common routine. Finally, the thing that's interesting about delegates is that they make it very easy to do dynamic routing of events. This is particularly interesting when you're doing data-driven instantiation of forms, where you read the database, figure out what fields you want to present, and then dynamically instantiate a bunch of edit controls or whatever. Then you bind their events so you can update the data that underlies them. Our delegate-based eventing model makes it very easy to do this. It's as easy to attach an event handler to a UI control as it is to modify a property. So there are many interesting advantages to delegates. </quote> On Thursday 03 October 2002 01:30 pm, Berin Loritsch wrote: > Steve Downey wrote: > > Only if you can explain why this version is NOT the same as the "evil", > > "destructive", <choose your own negative adjective> one that Microsoft > > implemented in J++. > > Uhmm, you'll have to tell me what you mean by that. I am not familiar > with J++ variances with the Java spec. > > We use JDK 1.3 dynamic proxies to put the implementation behind an > interface with only one method. You interact with that interface, > even though the underlying object/method combo does not have to have > the same name (although the rest of the signature has to be the same. > > It also works with Static Methods without requiring a public > constructor! > > > Or maybe people have forgotten that by now. > > I've *never* been exposed to it. > > > For the record, I thought they were a good idea when Anders first > > introduced them. They were a lot cleaner than the cruft introduced by > > AWT. > > Exactly! > > > I think there's likely some synergy between this and some of the > > proposals floating around for reflection utilities. > > > :) > > We have two versions of a Delegate: > > Delegate--An interface with one declared method that can return a value. > the implementation of the method can be a static method or an > object instance method as long as the parameters/return value/ > exception clauses are compatible. > > MultiDelegate--Similar to a Delegate except for the restriction that it > cannot return a value. It is used for event > notifications. One method call (like notifier.fire()) > can encapsulate calls to a whole set of delegates. > > The source code is in Excalibur Util CVS right now. We are shaking out > the bugs/fixing up the javadocs and will most likely be done either > today or tomorrow. > > If you are interested, take a look. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
