Interface and enums

[Bob]

Hi,
Can someone explain why you can't declare enums in an interface?
The compiler says "interfaces can't declare types"
Ignoring the syntax implications it seems to me that you should be able to
declare that an enum exists. i.e. It is within the 'spirit' of an interface
to state that it exists. The implementing class will provide the members.

e.g. I have a code library that performs a function.
It exposes two interfaces which allow for two different ways of asking for
the function.
One way involves a public enum, i.e. Some of the method calls accept the
enum as a parameter, the other does not.
It seems to me that I should be able to declare the enum in one interface
and leave it out of the other.
Currently the enum is available to declared objects of either interface.
e.g.
ImyFirstInterfa ce FirstInterface = new MyLib.myImpleme ntingclass();
ImySecondInterf ace SecondInterface = new MyLib.myImpleme ntingclass();

Both FirstInterface and SecondInterface can see MyLib.myPublicE num
thanks
Bob

[Mattias Sjögren]

>In the client code

>Once the ; is typed in
ICarFactory factory = new FordFactory();
Intellisense knows the contents of ModelEnum from its inspection of the
FordFactory implementation

No it doesn't. IntelliSense looks at the type of the variable. It
doesn't know about the actual implementing type used at runtime. Your
example is too simplistic. When using interfaces, it's very common to
not know the actual type that will be used.

Take a look at this for example

void Foo(bool preferAmericanC ars)
{
ICarFactory factory;
if (preferAmerican Car)
factory = new FordFactory();
else
factory = new ToyotaFactory() ;

factory.MakeCar (...

At this point, which "implementation " of the enum would you use? And
how would IntelliSense and the compiler know?
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Bob]

Hi Mattias,
Yep,
that is a weakness with my idea given the current semantics.

I guess what I am proposing here would need to be some sort of 'Sealed
Interface'
i.e. You can only declare say a 'IFordFactory' or a 'IToyotaFactory '

My real world situation that led to this line of reasoning is:
AppA has an internal widgetprocessin g class
AppB also processes widgets but does it using a DLL because it is
fundamentally different to AppA
Along comes a third party SuperWidgetProc essor class library that I want to
bolt on to AppA and also make available to AppB users who may or may not
decide to take it on board.

So I wrap SuperWidgetProc essor and expose its functionality through two
interfaces say IA and IB.
Easiest way to insert into AppA is to have the AppA WidgetProcessin g class
declare a private IA and route all its functionality to it. This way all
changes are confined to the WidgetProcessin g class.

Trouble is that the other classes tell the WidgetProcessin g class what they
want by passing in a request class that has Properties based on enums. So my
wrapper exposes a set of identically named enums and the routing code is
readable.
AppB uses a completely different approach so the enum thing is not needed.

So..
I am left with a wrapper that has a public enum that is useful to only one
out of two interfaces.
Hence my current line of reasoning of wanting to expose the enum only
through IA.

Ah well,
Perhaps in another life.
Thank you all for your thoughts.
regards
Bob

"Mattias Sjögren" <ma************ ********@mvps.o rgwrote in message
news:OU******** ******@TK2MSFTN GP04.phx.gbl...

In the client code
Once the ; is typed in
ICarFactory factory = new FordFactory();
Intellisense knows the contents of ModelEnum from its inspection of the
FordFactory implementation

No it doesn't. IntelliSense looks at the type of the variable. It
doesn't know about the actual implementing type used at runtime. Your
example is too simplistic. When using interfaces, it's very common to
not know the actual type that will be used.

Take a look at this for example

void Foo(bool preferAmericanC ars)
{
ICarFactory factory;
if (preferAmerican Car)
factory = new FordFactory();
else
factory = new ToyotaFactory() ;

factory.MakeCar (...

At this point, which "implementation " of the enum would you use? And
how would IntelliSense and the compiler know?
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[PS]

"Bob" <bo*@nowhere.co mwrote in message
news:uw******** ******@TK2MSFTN GP03.phx.gbl...

Hi Mattias,
Yep,
that is a weakness with my idea given the current semantics.

I guess what I am proposing here would need to be some sort of 'Sealed
Interface'
i.e. You can only declare say a 'IFordFactory' or a 'IToyotaFactory '

My real world situation that led to this line of reasoning is:
AppA has an internal widgetprocessin g class
AppB also processes widgets but does it using a DLL because it is
fundamentally different to AppA
Along comes a third party SuperWidgetProc essor class library that I want
to
bolt on to AppA and also make available to AppB users who may or may not
decide to take it on board.

So I wrap SuperWidgetProc essor and expose its functionality through two
interfaces say IA and IB.
Easiest way to insert into AppA is to have the AppA WidgetProcessin g class
declare a private IA and route all its functionality to it. This way all
changes are confined to the WidgetProcessin g class.

Trouble is that the other classes tell the WidgetProcessin g class what
they
want by passing in a request class that has Properties based on enums. So
my
wrapper exposes a set of identically named enums and the routing code is
readable.
AppB uses a completely different approach so the enum thing is not needed.

So..
I am left with a wrapper that has a public enum that is useful to only one
out of two interfaces.
Hence my current line of reasoning of wanting to expose the enum only
through IA.

I did get a little lost in your explanation. But if you want to keep "type
safety" with your enums then you can cast between different enums by
converting them to integers temporarily.

For example

enum CarModel
{
FordEscort = 1,
FordEscape = 2,
ToyotaRav4 = 3
}

enum FordModel
{
FordEscort = 1,
FordEscape = 2
}

enum ToyotaModel
{
ToyotaRav4 = 3
}

This way the FordFactory takes FordModel, the ToyotaFactory takes
ToyotaModel and your wrapper / abstract factory takes CarModel. The wrapper
/ abstract factory does need to do validate the values but after they are
validated they are converted like (ToyotaModel)(i nt)CarModel.Toy otaRav4.

Maybe this will help?

PS

>


"Mattias Sjögren" <ma************ ********@mvps.o rgwrote in message
news:OU******** ******@TK2MSFTN GP04.phx.gbl...

>In the client code
Once the ; is typed in
ICarFactory factory = new FordFactory();
Intellisense knows the contents of ModelEnum from its inspection of the
FordFactory implementation

No it doesn't. IntelliSense looks at the type of the variable. It
doesn't know about the actual implementing type used at runtime. Your
example is too simplistic. When using interfaces, it's very common to
not know the actual type that will be used.

Take a look at this for example

void Foo(bool preferAmericanC ars)
{
ICarFactory factory;
if (preferAmerican Car)
factory = new FordFactory();
else
factory = new ToyotaFactory() ;

factory.MakeCar (...

At this point, which "implementation " of the enum would you use? And
how would IntelliSense and the compiler know?
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[bob]

Hi PS,
I think my problem is that I didn't look at the big picture properly.
I got locked into trying to hide the enum from InterfaceB consumers. But
when I look downstream clearly the InterfaceB offering will be presented to
the consumers as a new version of their existng DLL so they won't see any of
the InterfaceA baggage anyway.
regards
Bob

<ec***********@ hotmail.comwrot e in message
news:Oq******** ********@TK2MSF TNGP02.phx.gbl. ..

>
"Bob" <bo*@nowhere.co mwrote in message
news:uw******** ******@TK2MSFTN GP03.phx.gbl...

Hi Mattias,
Yep,
that is a weakness with my idea given the current semantics.

I guess what I am proposing here would need to be some sort of 'Sealed
Interface'
i.e. You can only declare say a 'IFordFactory' or a 'IToyotaFactory '

My real world situation that led to this line of reasoning is:
AppA has an internal widgetprocessin g class
AppB also processes widgets but does it using a DLL because it is
fundamentally different to AppA
Along comes a third party SuperWidgetProc essor class library that I want
to
bolt on to AppA and also make available to AppB users who may or may

not

decide to take it on board.

So I wrap SuperWidgetProc essor and expose its functionality through two
interfaces say IA and IB.
Easiest way to insert into AppA is to have the AppA WidgetProcessin g

class

declare a private IA and route all its functionality to it. This way all
changes are confined to the WidgetProcessin g class.

Trouble is that the other classes tell the WidgetProcessin g class what
they
want by passing in a request class that has Properties based on enums.

So

my
wrapper exposes a set of identically named enums and the routing code is
readable.
AppB uses a completely different approach so the enum thing is not

needed.

So..
I am left with a wrapper that has a public enum that is useful to only

one

out of two interfaces.
Hence my current line of reasoning of wanting to expose the enum only
through IA.

I did get a little lost in your explanation. But if you want to keep "type
safety" with your enums then you can cast between different enums by
converting them to integers temporarily.

For example

enum CarModel
{
FordEscort = 1,
FordEscape = 2,
ToyotaRav4 = 3
}

enum FordModel
{
FordEscort = 1,
FordEscape = 2
}

enum ToyotaModel
{
ToyotaRav4 = 3
}

This way the FordFactory takes FordModel, the ToyotaFactory takes
ToyotaModel and your wrapper / abstract factory takes CarModel. The

wrapper

/ abstract factory does need to do validate the values but after they are
validated they are converted like (ToyotaModel)(i nt)CarModel.Toy otaRav4.

Maybe this will help?

PS

"Mattias Sjögren" <ma************ ********@mvps.o rgwrote in message
news:OU******** ******@TK2MSFTN GP04.phx.gbl...

In the client code
Once the ; is typed in
ICarFactory factory = new FordFactory();
Intellisense knows the contents of ModelEnum from its inspection of

the

FordFactory implementation

No it doesn't. IntelliSense looks at the type of the variable. It
doesn't know about the actual implementing type used at runtime. Your
example is too simplistic. When using interfaces, it's very common to
not know the actual type that will be used.

Take a look at this for example

void Foo(bool preferAmericanC ars)
{
ICarFactory factory;
if (preferAmerican Car)
factory = new FordFactory();
else
factory = new ToyotaFactory() ;

factory.MakeCar (...

At this point, which "implementation " of the enum would you use? And
how would IntelliSense and the compiler know?
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.