Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 15144 invoked from network); 3 Oct 2002 18:30:24 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 3 Oct 2002 18:30:24 -0000 Received: (qmail 10244 invoked by uid 97); 3 Oct 2002 18:30:05 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 10208 invoked by uid 97); 3 Oct 2002 18:30:04 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 10191 invoked by uid 98); 3 Oct 2002 18:30:04 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Content-Type: text/plain; charset="iso-8859-1" From: Steve Downey To: "Jakarta Commons Developers List" Subject: Re: [lang] Proposal for *NEXT* version Date: Thu, 3 Oct 2002 14:26:41 -0400 User-Agent: KMail/1.4.1 References: <3D9C56F9.7070607@apache.org> <200210031235.26731.steve.downey@netfolio.com> <3D9C7E9E.80109@apache.org> In-Reply-To: <3D9C7E9E.80109@apache.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200210031426.41825.steve.downey@netfolio.com> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N =46rom http://msdn.microsoft.com/library/en-us/dndevqa/html/msdn_andersh.= asp, an=20 interview with Anders Hejlsberg, the original architect of Borland's Delp= hi,=20 regarding some of the work he had done for the "Windows Foundation Classe= s",=20 part of Microsoft's J++ product, after he jumped ship from Borland.=20 His work was later adopted into C#.=20 It was also a key point in Sun's complaints about the MS Java implementat= ion,=20 because they introduced a keyword 'delegate' to implement it, as dynamic=20 proxies were not available. Also, as a language feature, MS's delegates c= ould=20 be statically checked against method signatures at compile time.=20 MSDN: Can you describe the new eventing model in WFC, which uses somethin= g you=20 call delegates? Hejlsberg: The technically correct term for delegates is "bound method=20 references." If you think about the ActiveX or JavaBeans eventing models,= =20 they both use interfaces for eventing. We use delegates, or bound method=20 references. For example, in the ActiveX or JavaBeans world, if you have a button that= =20 wants to fire an event, it does so by defining an interface. Someone has = to=20 implement that interface and then give it to the button so the button can= =20 call back on that interface, in order to fire events. In the WFC component model, a button essentially has a bound method refer= ence=20 that it calls when you click on the button. You don't have to implement a= n=20 interface in order to receive the event. You simply have to supply an obj= ect=20 and a method and say to the button, "When you're clicked, just call this=20 method on this object." So it's a simpler model. It's also a more flexibl= e=20 model. If you look at how JavaBeans tools today implement eventing, they have a=20 problem. Let's say you have a form that has 100 buttons on it, and you wa= nt=20 to have a separate event handler for each button. Now you need to impleme= nt=20 this event interface 100 times, but you can't, you can only implement tha= t=20 interface once. You're faced with either having to write 100 adapter classes--that is, li= ttle=20 classes that each implement the button interface and then forward it to t= he=20 particular event handler--or you have to write one handler that has a=20 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=20 footprint, or you're trading speed away. But with the WFC delegate model,= =20 you're not trading anything away. The other thing that's interesting about delegates--and particularly how = we=20 implemented delegates --is that we can do automatic multicasting of event= s. A=20 control that fires an event sees essentially one bound method reference, = one=20 delegate that it calls to. That delegate will (underneath the hood)=20 potentially call many receivers of the event. This all happens automatica= lly,=20 and with great efficiency. Another thing that's interesting about delegates is they allow you to do=20 many-to-one mapping of event handlers. Because you're just referencing=20 methods, you can have a button click and a menu click both go to the same= =20 event handler. You don't have to write these things that forward the call= to=20 a common routine. Finally, the thing that's interesting about delegates is that they make i= t=20 very easy to do dynamic routing of events. This is particularly interesti= ng=20 when you're doing data-driven instantiation of forms, where you read the=20 database, figure out what fields you want to present, and then dynamicall= y=20 instantiate a bunch of edit controls or whatever. Then you bind their eve= nts=20 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=20 to attach an event handler to a UI control as it is to modify a property.= So=20 there are many interesting advantages to delegates.=20 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", one that Microsof= t > > 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= =2E > the implementation of the method can be a static method or a= n > object instance method as long as the parameters/return valu= e/ > 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: For additional commands, e-mail: