> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> 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.
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.
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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
