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