C# Feature Request (Interface Extensions)

[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(ISomeInte rface 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

[Nicolas di Tada]

Re: C# Feature Request (Interface Extensions)

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, "christophe r diggins"
<cdiggins@users .sourceforge.ne t> wrote:
[color=blue]
>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(ISomeInte rface 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.[/color]

[Philip Rieck]

Re: C# Feature Request (Interface Extensions)

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 SomeAbstractBas e{
public void SomeContractFun ction();
public void FuBar(){
SomeContractFun ction();
}
}


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.



"christophe r diggins" <cdiggins@users .sourceforge.ne t> wrote in message
news:0NaUb.9141 3$d15.1983790@w eber.videotron. net...[color=blue]
> 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[/color]
purpose[color=blue]
> function to operate on all objects which implement that interface is[/color]
through[color=blue]
> the following style of declaration (in the following code snippets i is an
> interface variable of type ISomeInterface) :
>
> SomeStaticClass {
> FuBar(ISomeInte rface 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[/color]
of[color=blue]
> 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[/color]
first[color=blue]
> 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[/color]
and[color=blue]
> 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
>
>[/color]

[christopher diggins]

Re: C# Feature Request (Interface Extensions)

<Nicolas di Tada> wrote in message
news:1hr220t655 58knjhncrnabvvj 7jlpl550q@4ax.c om...[color=blue]
> Why don't you just use abstract classes?
>
> Nicolas di Tada
> Manas - Technology Solutions
> http://www.manas.com.ar[/color]

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

[christopher diggins]

Re: C# Feature Request (Interface Extensions)


"Philip Rieck" <stuff@mckraken .com> wrote in message
news:u5vIo036DH A.2996@tk2msftn gp13.phx.gbl...[color=blue]
> Once you add functionality to an interface, it is no longer an interface -
> it's a class.[/color]

By some defintions, but we shouldn't allow ourselves to be boxed in by
definitions.
[color=blue]
> And you don't end up as a static class like the code you posted, you end[/color]
up[color=blue]
> with
> public abstract class SomeAbstractBas e{
> public void SomeContractFun ction();
> public void FuBar(){
> SomeContractFun ction();
> }
> }[/color]

This is a work-around but not functionally equivalent to what I posted.
[color=blue]
>
> unless what you REALLY want is multiple inheritance, which c# does *not*
> have.[/color]

That is not what I really want. I am aware C# does not have multiple
inheritance of classes.
[color=blue]
> 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[/color]
it[color=blue]
> has caused me a problem. Many people consider missing MI to be a huge[/color]
lack.[color=blue]
> Others think its a boon.[/color]

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.
[color=blue]
> 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.[/color]

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