commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Downey <steve.dow...@netfolio.com>
Subject Re: [lang] Proposal for *NEXT* version
Date Thu, 03 Oct 2002 18:26:41 GMT
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:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message