C# Feature Request (Interface Extensions)

  • Thread starter Thread starter christopher diggins
  • Start date Start date
C

christopher diggins

A feature that I find signficantly missing in C# is the ability to write
functions in interfaces that can call other functions of the interface.
Given an interface ISomeInteface the only way we can write a general purpose
function to operate on all objects which implement that interface is through
the following style of declaration (in the following code snippets i is an
interface variable of type ISomeInterface) :

SomeStaticClass {
FuBar(ISomeInterface i) { ... }
}

Which when invoked requires the following syntax :

SomeStaticClass.FuBar(i);


What would be more appropriate would be to be able to define interface
functions which allow the more straightforward object-like syntax of :

i.FuBar()

For lack of a better term I refer to these kinds of functions as interface
extensions, in order to distinguish them from interface contract (the set of
functions to be implemented, by an implementor of the interface). One
possible approach for adding this feature is to prefix extension functions
with a keyword modifier, such as in the following notation :

SomeInterface {
extension FuBar() { ... }
}

Another possibility, and my preferred option, is to divide the interface
into two sections :

SomeInterface {
contract
...
extension
FuBar();
}

For more information on extensions as implemented by Heron, there is a first
draft of a paper at : http://www.heron-language.com/extensions.html . I
would like to know what others think of this proposal (both the feature and
the presentation of the feature) and what the proper channels are for
feature proposal to C#. Thanks in advance for your feedback.
 
Once you add functionality to an interface, it is no longer an interface -
it's a class.

And you don't end up as a static class like the code you posted, you end up
with
public abstract class SomeAbstractBase{
public void SomeContractFunction();
public void FuBar(){
SomeContractFunction();
}
}


unless what you REALLY want is multiple inheritance, which c# does *not*
have.

While I think there are a lot of good arguments about multiple inheritance
both ways, I can easily count on one hand the number of times not having it
has caused me a problem. Many people consider missing MI to be a huge lack.
Others think its a boon.

However, making interfaces into abstract classes but still calling them
interfaces isn't going to resolve the issue -- it's just renaming it.
Renaming it in a confusing way, at that.
 
Why don't you just use abstract classes?

Nicolas di Tada
Manas - Technology Solutions
http://www.manas.com.ar
Click to expand...

Because you can not have multiple inheritance of base classes.

Conceptually an extension is a top-down approach rather than a bottom up
approach. Using an abstract class to express a contract as in an interface
is not clear design concept, if it were then there would be no need to
explicitly have interfaces in the first place.
 
Philip Rieck said:
Once you add functionality to an interface, it is no longer an interface -
it's a class.
Click to expand...

By some defintions, but we shouldn't allow ourselves to be boxed in by
definitions.
And you don't end up as a static class like the code you posted, you end up
with
public abstract class SomeAbstractBase{
public void SomeContractFunction();
public void FuBar(){
SomeContractFunction();
}
}
Click to expand...

This is a work-around but not functionally equivalent to what I posted.
unless what you REALLY want is multiple inheritance, which c# does *not*
have.
Click to expand...

That is not what I really want. I am aware C# does not have multiple
inheritance of classes.
While I think there are a lot of good arguments about multiple inheritance
both ways, I can easily count on one hand the number of times not having it
has caused me a problem. Many people consider missing MI to be a huge lack.
Others think its a boon.
Click to expand...

Unless what I really want are interface with extensions. Interfaces with
extensions do not introduce all of the properties of multiple inheritance.
For instance you do not have multiple inheritance of data, nor do you have
multiple inheritance of contract implementation. Comparing it with multiple
inheritance of classes is just not correct.
However, making interfaces into abstract classes but still calling them
interfaces isn't going to resolve the issue -- it's just renaming it.
Renaming it in a confusing way, at that.
Click to expand...

You are oversimplifying what I proposed. An abstract base class is not
equivalent to an interface with extensions. Some of the differences are :
1) interface with extensions can not contain data
2) the implementation of an interface with extension can not also be an
interface with extensions
3) you can not partially implement the contract of an interface with
extensions
4) you can not have virtual yet non-abstract functions in an interface with
extensions
5) you can inherit multiple interfaces (as you pointed out),

Overall the problems with ABC's is that they blur the distinction between
divisions of interface and implementation.

Best regards,

Christopher Diggins
yet another language designer
http://www.heron-language.com
 
Back
Top