Informal interfaces
Fredrik Olsson
peylow at gmail.com
Mon Oct 2 01:42:43 PDT 2006
An interface is a definition of what *must* be implemented.
An informal interface is a definition of what *could* be implemented.
Java's awt uses the EventListener interface for defining delegate object
that can handle UI controls events. The idea is sound, but the
implementation has a few flaws.
As it uses events, all methods must be implemented, even if only a
single event is of interest. To solve this there are classes for most
interfaces that implements all methods with dummy methods, and then you
just override what you need. As Jave (And D) does not have multiple
inheritance this add another restriction; a delegate object can only
handle a single control (or type of control), not a whole window.
In Cocoa (Objecive-C) interfaces are called protocols, different name,
same thing. Cocoa also have informal protocols. Event listening
protocols are informal. An informal protocol only declare what methods
can be implemented, without enforcing them. Not implementing a method
simply means that you are not interested int hat event, and the runtime
will filter it for you.
I suggest that D add support for informal interfaces using one new
keyword, and one new property on all objects.
First methods in interfaces could be marked with he keyword "optional".
Marking a method as optional in an interface will make the interface
informal, just as marking a method abstract in a class will make the
class abstract. A method marked as optional would have two properties:
1. Not even a warning if unimplemented by a class implementing the
interface,
2. Calling the method if unimplemented will do nothing if void, or
return a default value if any other type.
Example:
interface FooDelegate {
optional void doA();
optional int askB();
optional bool isC() = true;
}
All three methods are optional. If doA() is unimplemented nothing will
happen if it is called. if askB() is called then int.init will be
returned. And if isC() is called true will be returned.
If any or all of the three are implemented then it is naturaly up to the
implementation to return a proper value.
I attach a file with a longer example fo how it could be useful and work
in a real world example.
All problems from Java EventListener paradigm are solved; no need to
implement unneeded methods, a delegate object can listen to any number
of objects, the object declaring the informal protocol is also free to
declare the defaults.
I believe the actual implementation can be very simple. All optional
methods need to be virtual. Optional methods and unimplemented methods
have a NULL entry int the virtual method table. A method dispatch that
normally would be (I use 68k asm for readability :) ):
move.l 16(a1),a0
jsr (a0)
Would now become:
move.l 16(a1),a0
beq.s .skip
jsr (a0)
.skip:
A small price to pay, slightly more for non voids. Non default return
values, anything different from type.init could be a problem, at least
if no access to the original source. The value to use must be available
somehow. I have though about letting the optional methods have dumy
implementation returning the value, that could then be an expression and
not a constant. But I think the testing for implemented methods would
become more complex, and calling a method could be more costly that
testing for NULL and branch, todays CPUs are good at branch prediction.
Secondly all objects need a new property, a simple property to test for
the availability of a method on objects. I suggest this:
public bool implements(method_signature);
And it would be used something along this line:
if (someObject.implements(doSomething(int))) {
// prepare some costly stuff stuff
someObject.doSomething(the_costly_result);
}
// Fredrik Olsson
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: delegate.d
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20061002/6d24b954/attachment.ksh>
More information about the Digitalmars-d
mailing list