Declaring types in an Interface

[Peter Berry]

I was surprised and somewhat disappointed by the fact that you cannot declare types in an interface. I discovered this when defining an interface that included events, where the definition of the delegates had to be placed outside the definition of the interface. To me, the delegate definition is an integral part of the interface definition. Also, I could imagine cases where one would like to define enums and structs in interfaces as well (to be used as parameter types in methods of the interface). The way it is now, these "external" definitions have to be carried along as added baggage to the interfaces, and clients have to be aware of this. They are even listed separately from the interface in the Class View tree list in Visual Studio - unless the type is given some meaningful name tag to associate it with its interface, there is no indication as to what it belongs to.

Am I missing something here, or is this a reasonable request for inclusion in a future version of the language? I would very much appreciate your comments on this.

Peter Berry

[Richard A. Lowe]

In regards to delegates, I can say that it's a blessing that you only need
to match the signature, and not have a class implement an interface in order
to handle an event, not sure if that's what you meant, though. I don't know
what exactly your scenarios are for embedding enums in interfaces? If you
want to pass around a type with a restricted set of values, seems to me
you'd want to have it available freely detached from any interface that used
that type as a member - but that may not be your scenario. I guess I just
don't see what you 'buy' with it.

R.

--
Veuillez m'excuser, mon Français est très pauvre. Cependant, si vous voyez
mauvais C #, c'est mon défaut!
"Peter Berry" <bc******@bigpond.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
I was surprised and somewhat disappointed by the fact that you cannot
declare types in an interface. I discovered this when defining an interface
that included events, where the definition of the delegates had to be placed
outside the definition of the interface. To me, the delegate definition is
an integral part of the interface definition. Also, I could imagine cases
where one would like to define enums and structs in interfaces as well (to
be used as parameter types in methods of the interface). The way it is now,
these "external" definitions have to be carried along as added baggage to
the interfaces, and clients have to be aware of this. They are even listed
separately from the interface in the Class View tree list in Visual Studio -
unless the type is given some meaningful name tag to associate it with its
interface, there is no indication as to what it belongs to.
Am I missing something here, or is this a reasonable request for inclusion
in a future version of the language? I would very much appreciate your
comments on this.
Peter Berry

[Dan Holmes]

i would really like constants to be available in the interface.

dan holmes
"Peter Berry" <bc******@bigpond.com> wrote in message news:%2****************@TK2MSFTNGP11.phx.gbl...
I was surprised and somewhat disappointed by the fact that you cannot declare types in an interface. I discovered this when defining an interface that included events, where the definition of the delegates had to be placed outside the definition of the interface. To me, the delegate definition is an integral part of the interface definition. Also, I could imagine cases where one would like to define enums and structs in interfaces as well (to be used as parameter types in methods of the interface). The way it is now, these "external" definitions have to be carried along as added baggage to the interfaces, and clients have to be aware of this. They are even listed separately from the interface in the Class View tree list in Visual Studio - unless the type is given some meaningful name tag to associate it with its interface, there is no indication as to what it belongs to.

Am I missing something here, or is this a reasonable request for inclusion in a future version of the language? I would very much appreciate your comments on this.

Peter Berry

[Zhanyong Wan [MSFT]]

I cannot speak for the C# designers, but my guess is that they were trying
to keep the language not unnecessarily complex.

The features you mentioned, while missed, are not indespensable. You can
achieve similar results using nested name spaces and/or abstract classes.
Like

public abstract class Foo
{
public enum Bar {...}
public const Baz = ...;

public int Method1() {...}
}

- Zhanyong Wan

Visual Studio and .NET Setup

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included samples (if any) is subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

--------------------
| From: "Dan Holmes" <dh*****@ivsi.com>
|
| i would really like constants to be available in the interface.
| dan holmes
| "Peter Berry" <bc******@bigpond.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
| I was surprised and somewhat disappointed by the fact that you cannot
declare types in an interface. I discovered this when defining an interface
that included events, where the definition of the delegates had to be
placed outside the definition of the interface. To me, the delegate
definition is an integral part of the interface definition. Also, I could
imagine cases where one would like to define enums and structs in
interfaces as well (to be used as parameter types in methods of the
interface). The way it is now, these "external" definitions have to be
carried along as added baggage to the interfaces, and clients have to be
aware of this. They are even listed separately from the interface in the
Class View tree list in Visual Studio - unless the type is given some
meaningful name tag to associate it with its interface, there is no
indication as to what it belongs to.
| Am I missing something here, or is this a reasonable request for
inclusion in a future version of the language? I would very much appreciate
your comments on this.
| Peter Berry
|

[Marius Horak]

My comment is - interface is a pain in my neck.
I cannot see any benefits of using interface.

I have to modify a system where everything is based on some kind of
interface.
I need to make a major change to one of the components. It's based on
interface and another 29 components are based on the same interface.
So either I modify that component by removing reference to the base
interface (if so, why to use interface at all) or I will have to modify
the interface and 29 components.

I will never,never use interface.

MH

[Ignacio Machin \( .NET/ C# MVP \)]

Hi ,
"Marius Horak" <so*****@europe.con> wrote in message
news:uk**************@TK2MSFTNGP09.phx.gbl...

My comment is - interface is a pain in my neck.
I cannot see any benefits of using interface.
An interface is a contract, it's a corner stone of the OOP paradigm and
frankly you cannot do much in C# without using them. I could give you a
large explanation of the beneficies of them, but no today ;)
Maybe if you do a search in google for something like 'interface vs
"multiple inheritance"' you will get some links with better explanation of
the one I would possible give you.
I have to modify a system where everything is based on some kind of
interface.
You should NEVER modify an interface !!! an interface is a contract and must
be kept both by the classes that implement them as well as the interface
itself.
I need to make a major change to one of the components. It's based on
interface and another 29 components are based on the same interface.
So either I modify that component by removing reference to the base
interface (if so, why to use interface at all) or I will have to modify
the interface and 29 components.

Did you think about creating a new interface that inherit from the previous
one?
In this case you will have to modify only the component that you want, and
not the entire system.

Maybe if you create a derived class of that component that implement the new
interface you can solve your problem.
Merry X-Mas,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation