[2165] in java-interest
Re: interfaces are NO substitution for method pointers
daemon@ATHENA.MIT.EDU (Ken Arnold - Sun Labs)
Tue Sep 26 13:17:15 1995
Date: Tue, 26 Sep 1995 10:27:32 -0400
From: arnold@cocolat.East.Sun.COM (Ken Arnold - Sun Labs)
To: java-interest@java.Eng.Sun.COM
I suppose I'm not as wise as Arthur -- I'm going to take *one* crack
at trying to convince.
Using methods, if you want, say, a callback from a button click, you
say something like this (in the officially approved signature):
void CancelButtonCallbackFunc(Button *button, void *my_data)
{
do_cancel((Operation *) my_data); // whatever
}
Using an interface, it would look like this:
class CancelButtonCallback extends Button {
Operation *my_data;
void pressed()
{
do_cancel(); // whatever
}
}
Over this you make a noise? In the first case, you have to
invent a name for the new function
create the button with a void * for your own data
receive a button * to tell you which button
receive a void * you cast back to your own data
do your thing
In the second case you have to
invent a name for the new button type
create a button of that new type
have any data you want as data member (type safe, notice no casting)
do your thing
At the very worst, you can argue that the new system maybe has a very
few more keystrokes. You have to admit that it adds some type safety,
and arguably OO cleanliness and reusability. This doesn't sound like a
problem to me. In fact, it smells a lot like a *solution* to some
problems.
Ken Arnold
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
