avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Wanting delegates
Date Thu, 03 Oct 2002 13:03:16 GMT
Leo Sutic wrote:
> 
>>From: Berin Loritsch [mailto:bloritsch@apache.org] 
>>
>>Delegates are the key to programming intelligent agents--such 
>>as the type that would be needed to determine the best set of 
>>components for an assembly file.  The proper matching can be 
>>performed with generic search algorithms that use specific 
>>methods as parameters to the search algorithm.
>>
>>I decided that it would be relatively easy to throw together 
>>an inheritance based Delegate mechanism.  The class is in 
>>Excalibur Util along with an example in the TestCase.
>>
>>There are some limitations to the Delegate mechanism:
>>
>>1) the Object must be accessible to the 
>>org.apache.excalibur.util package
>>    (which means that the object is public).
> 
> 
> Seems reasonable.
>  
> 
>>2) the method must be public--no other access level will even 
>>be considered.
> 
> 
> Seems very reasonable.
> 
> 
>>3) The method cannot be named the same as any of the standard 
>>Object methods.
> 
> 
> Seems reasonable.
>  
> 
>>These are out of necessity and the way the reflection package 
>>works. The reason the method names cannot be the same as any 
>>standard Object method is that there is no other way to 
>>determine what method the Delegate needs to implement.
> 
> 
> Berin, 
> 
> I am +1 for exploring this. But I think a scratchpad is the proper 
> place for it. I don't like your implementation as it is now and
> I'm -1 on putting it into excalibur/util in the state it is now.

Util is a scratchpad.


> A delegate is basically a method pointer. I assume that the
> difference between calls via a delegate a through an interface
> is that you can name the method anything you want.

Yes and no.  A delegate is a way of treating a Method like an
Object.  The end result is similar, but the implications are
different.

The implementation as it is now (I threw it together last night
at midnight) is the beginning.  What would be perfect is something
backed by BCEL so that all we have to do is "create" a new keyword.

If I had a line like this:

delegate MyDel = new delegate String echo( String );

then I would be able to have a new delegate class created on the
spot with the face:

String answer = MyDel.echo( "message" );

Of course, something along the lines of a proxy factory would be
worth exploring.

> 
> Therefore, when creating a delegate, you should be able to name
> the method:
> 
> interface Interface {
>   void delegate (); // This can be anything. It is the signature of the
>                     // delegate method.
> }
> 
> class MyClass {
> 
>   void myMethod () {
>     // The method I want to delegate to.
>   }
> 
>   void doDelegation {
>     Interface myDelegate = 
>         (Interface) Delegate.newDelegate (this, "myMethod", Interface);
> 
>     myDelegate.delegate (); // Calls myMethod.
>   }
> 
> }
> 
> The Delegate.newDelegate creates a proxy etc...
> 
> This means code will be like this:
> 
> public class Button {
> 
>   public interface OnPressedHandler {
>     public void action ();
>   }
> 
>   OnPressedHandler onPressed = null;
> 
>   public void delegatePressedEventFromAWT () {
>     onPressed.action ();
>   }
> 
>   public void setOnPressed (OnPressedHandler handler) {
>     onPressed = handler;
>   }
> }
> 
> 
> public class ButtonUser {
> 
>   Button button1 = new Button ();
>   Button button2 = new Button ();
> 
>   public void onButton1 () {
>     // ---
>   }
> 
>   public void onButton2 () {
>     // ---
>   }
> 
>   public void setup () {
>     button1.setOnPressed (
>         (Button.OnPressedHandler) Delegate.newDelegate 
>             (this, "onButton1", Button.OnPressedHandler));
> 
>     button2.setOnPressed (
>         (Button.OnPressedHandler) Delegate.newDelegate 
>             (this, "onButton2", Button.OnPressedHandler));
>   }
> }
> 
> Warning: I have no idea if the above is feasible. (I have not
> implemented it yet.) But I think so.
> 
> /LS
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
> 


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message