C# language requires overspecification of interfaces

[Fred Mellender]

I would like to make a library (dll) that contains a number of classes and
interfaces for use by other implementers. One of the interfaces I want to
define is:


public interface Foo
{
Bar MakeABar();
}

It seems that C# compiler requires that I define Bar in the library,
complaining:
"The type or namespace name 'Bar' could not be found (are you missing a
using directive or an assembly reference?)"

But I want users of my library to define their own Bar, and to implement
MakeABar in any of their classes that inherit from my interface via their
own Bar. Indeed, I want them to be able to define different implementations
of Bar in different projects, and to use my library in each.

C++ has the construct:

Class Bar;

Which lets you mention the type Bar without defining it. It even lets me
define MakeABar as

Bar MakeABar()
{
return null;
}
without having to define the class Bar. I could put some sort of dummy Bar
class in my library and have users inherit from it but that does not work
for my purposes since I do not want the users to have to downcast in order
to use the object returned from MakeABar.

To be honest upcoming "generics" will (?) solve my specific problem, but I
wonder if the C# designers might consider a construct like "Class Bar;" with
a usage similar to that in C++. If not, why not?

 

[Jon Skeet [C# MVP]]

I would like to make a library (dll) that contains a number of classes and
interfaces for use by other implementers. One of the interfaces I want to
define is:


public interface Foo
{
Bar MakeABar();
}

It seems that C# compiler requires that I define Bar in the library,

Nope - either the library, or one of the assemblies it references.

complaining:
"The type or namespace name 'Bar' could not be found (are you missing a
using directive or an assembly reference?)"

But I want users of my library to define their own Bar, and to implement
MakeABar in any of their classes that inherit from my interface via their
own Bar.

You can't do that. You have to just declare it as Object - which is
reasonable, as you don't know anything more about Bar than you do about
Object, do you? The downside of this is that you can't have two methods
in the interface which must return the *same* (unknown in advance)
type.

I suspect generics will let you do the latter though - mind you, I
haven't checked that.

To be honest upcoming "generics" will (?) solve my specific problem, but I
wonder if the C# designers might consider a construct like "Class Bar;" with
a usage similar to that in C++. If not, why not?

It sounds like a really bad idea to me - it's pretending the compiler
knows something about the class when it doesn't. What's wrong with just
using Object? If you really wanted to, you could always define an empty
interface which Bar could then implement.

 

[Girish Bharadwaj]

I would like to make a library (dll) that contains a number of classes and
interfaces for use by other implementers. One of the interfaces I want to
define is:


public interface Foo
{
Bar MakeABar();
}

It seems that C# compiler requires that I define Bar in the library,
complaining:
"The type or namespace name 'Bar' could not be found (are you missing a
using directive or an assembly reference?)"

But I want users of my library to define their own Bar, and to implement
MakeABar in any of their classes that inherit from my interface via their
own Bar. Indeed, I want them to be able to define different implementations
of Bar in different projects, and to use my library in each.

C++ has the construct:

Class Bar;

Which lets you mention the type Bar without defining it. It even lets me
define MakeABar as

Bar MakeABar()
{
return null;
}
without having to define the class Bar. I could put some sort of dummy Bar
class in my library and have users inherit from it but that does not work
for my purposes since I do not want the users to have to downcast in order
to use the object returned from MakeABar.

To be honest upcoming "generics" will (?) solve my specific problem, but I
wonder if the C# designers might consider a construct like "Class Bar;" with
a usage similar to that in C++. If not, why not?

Taking your Example wouldn't it be simple to do


public interface IBar {
}

public interface IFoo {
IBar GetBar();
}
....
This means that the object implementing IFoo agrees that it will return
an object that implements an empty interface called IBar that does
whatever it pleases and exposes its own set of methods.

Isn't this the same as what you are attempting with C++ code.

The only difference though.. in C++, you ultimately will be declaring
the fact that Bar is a real class somewhere in your compiled code.

That is not the same as an interface which can be used accross
assemblies. In which case.. The C++ analogy will not fit. So..

I think I am trying to say that C++ analogy does not fit the C# paradigm
very well. You should be comparing it with either the Java "interface"
or the COM IDL "interface". And in both those cases, interfaces will
need specification of the types referenced within that interface
declaration.

 

[Fred Mellender]

The main point is that I do not want users of my interface to have to
downcast the object returned by MakeABar, which they would have to do if I
return either Object or IBar. It seems to me that "interfaces" should be
entirely independent of implementation. Yet I must reveal the
implementation of any of the types I use in the interface (in so far as I
have to point, via "using", to an actual implementation) or I get the
compiler error.

I could make the same case for classes: I should be able to use the
type-name without having had to implement it, unless I make a reference to a
member of the class (as in C++). But it seems to me the case is even
stronger for interfaces since they are supposed to allow one to postpone the
implementation until a class actual inherits from it.

Thanks for your comments.

 

[Daniel O'Connell]

The main point is that I do not want users of my interface to have to
downcast the object returned by MakeABar, which they would have to do if I
return either Object or IBar. It seems to me that "interfaces" should be
entirely independent of implementation. Yet I must reveal the
implementation of any of the types I use in the interface (in so far as I
have to point, via "using", to an actual implementation) or I get the
compiler error.

Indepedence from implementation and indepedence from clearly defined types
are two different things. In this particular design, why are you even using
an interface? If the interface cannot be used as a black box, then its not
worth BEING an interface, it has no polymorphic use to another class in any
way.

I could make the same case for classes: I should be able to use the
type-name without having had to implement it, unless I make a reference to a
member of the class (as in C++). But it seems to me the case is even
stronger for interfaces since they are supposed to allow one to postpone the
implementation until a class actual inherits from it.

You should NEVER be able to use a type name for an undefined type. Such code
is horrible, IMHO, and something that should not be done in any, any case.
Part of the goal of C# is a strong typed nature, a type name that defines no
type is not strongly typed. It breaks interoperability, no given interface
can be used generically when such a thing happens, it turns an interface
into nothing but a member template.

Even some of the suggestions made to do what you want are troublesome. What
purpose does the interface serve if it can only be used by one application?
If you are seperating interface from implementation, but not really...why
are you using interfaces and just not creating your own classes to do the
job?

I've said this many times, C# is NOT C++, and you really have to give up the
C++ ideas you are used to or you will not find much success in C#.

Thanks for your comments.

want

to

dummy

Bar

Bar;"

 

[bullshark]

I would like to make a library (dll) that contains a number of classes and
interfaces for use by other implementers. One of the interfaces I want to
define is:


public interface Foo
{
Bar MakeABar();
}

It seems that C# compiler requires that I define Bar in the library,
complaining:
"The type or namespace name 'Bar' could not be found (are you missing a
using directive or an assembly reference?)"

But I want users of my library to define their own Bar, and to implement
MakeABar in any of their classes that inherit from my interface via their

Once again, the call is made to make a Sow's ear out of a Silk purse.

bullshark

 

[gerry]

just have to wait for generics to appear in c#

 

[TPECHAT]

Try an abstract class.