By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,569 Members | 1,422 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,569 IT Pros & Developers. It's quick & easy.

C# Feature Request (Interface Extensions)

P: n/a
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.

--
Christopher Diggins
yet another language designer
http://www.heron-language.com
Nov 15 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Why don't you just use abstract classes?

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

On Wed, 4 Feb 2004 13:25:49 -0500, "christopher diggins"
<cd******@users.sourceforge.net> wrote:
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.


Nov 15 '05 #2

P: n/a
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.

"christopher diggins" <cd******@users.sourceforge.net> wrote in message
news:0N*********************@weber.videotron.net.. .
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.

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

Nov 15 '05 #3

P: n/a
<Nicolas di Tada> wrote in message
news:1h********************************@4ax.com...
Why don't you just use abstract classes?

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


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.

--
Christopher Diggins
yet another language designer
http://www.heron-language.com
Nov 15 '05 #4

P: n/a

"Philip Rieck" <st***@mckraken.com> wrote in message
news:u5**************@tk2msftngp13.phx.gbl...
Once you add functionality to an interface, it is no longer an interface -
it's a class.
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();
}
}
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.
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.
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.


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
Nov 15 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.