To interface or not to interface

Michel Fortin michel.fortin at
Tue May 25 08:03:43 PDT 2010

On 2010-05-25 10:01:48 -0400, Jacob Carlborg <doob at> said:

> Now Item could be an interface but it don't have to be. I suggest you 
> have a look at Apple's documentation of NSTableView:

What Cocoa is doing is basically allowing 'optional' methods in an 
interface (a protocol in Objective-C). Taking your example, the 
NSTableViewDataSource protocol contains a lot of functions to provide 
the required data to a table. But many of them are optional: for 
instance a data source that does not implement the 
"...setObjectValue..." method will prevent the table's content from 
being edited, one that doesn't implement the 
"...sortDescriptorsDidChange..." method prevents the table from being 
sorted by clicking on its column headers, one that doesn't implement 
the various methods for drag and drop will prevent rows from being 

(Note to Cocoa programmers: Prior to the Mac OS X 10.6 SDK, 
NSTableViewDataSource was an informal protocol implemented as a 
category of unimplemented functions in NSObject. The 10.6 SDK changed 
it to be a formal protocol with optional methods, a feature added to 
Objective-C 2.0.)

In D, one could create one interface for each of these groups of 
things, but then you'll have a bazilion of small interfaces and either 
you lose the relation between them or you end up with a combinational 
explosion. For instance, let's create a bunch of interfaces for what I 
wrote above:

	interface TableDataSource {...}
	interface TableDataSourceEdit : TableDataSource {...}
	interface TableDataSourceSort : TableDataSource {...}
	interface TableDataSourceDrag : TableDataSource {...}
	interface TableDataSourceDropTarget : TableDataSource {...}

Now, when I implement the table view I could have one data source

	class TableView {
		TableDataSource dataSource;

and then I'd dynamically check whether my data source implements each 
of the child interfaces:

	auto dataSourceEdit = cast(TableDataSourceEdit)dataSource)
	if (dataSourceEdit) {
		dataSourceEdit.setObject(object, row, column);
	} else {
		// data source cannot be edited

That's essentially what is done in Cocoa, except that in Cocoa an 
object usually checks for the existence of one of its delegate function 
prior calling it instead of having a whole lot of interfaces. This is 
why protocols are allowed to have optional methods.

Perhaps interfaces could be allowed to have optional methods that would 
require you to check if they're implemented before use.

Michel Fortin
michel.fortin at

More information about the Digitalmars-d mailing list