views:

171

answers:

4

Hey all,

I've seen a couple similar threads to this question, but none of them really answer the question I want to ask.

For starters, unfortunately I'm working with existing API code so sadly, while there may be a better way to do what I'm asking about, I'm locked in to doing it similarly to the way it is because backwards compatibility is non-negotiable.

I have a response class that currently contains an enum for an error code and a string description. The error codes define a fairly nice and complete set of responses that are all very semantically coupled to the operations where they're used.

Unfortuantely, I now have to add a different workflow for a similar set of API objects, and this will require a string description, which is fine, but also an enum error code consisting of a totally unrelated set of error codes. The error codes (and other aspects of the object model) will be used in lots of the same classes, so it would be nice to get a interface going so that i can run the objects through the same framework.

The intent here is to make a contract that says "I have an error code, and a description of that error code."

However, as far as I know there's no way to add an item to an interface such as

public interface IError
{
    enum ErrorCode;
    string Description;
}

nor is there a way to express

public interface IError<T> where T: enum
{
    T ErrorCode;
    string Description;
}

Anyone every run up against something like this before?

+7  A: 

Yes, I've run up against this. Not in this particular situation, but in other Stack Overflow questions, like this one. (I'm not voting to close this one as a duplicate, as it's slightly different.)

It is possible to express your generic interface - just not in C#. You can do it in IL with no problems. I'm hoping the limitation may be removed in C# 5. The C# compiler actually handles the constraint perfectly correctly, as far as I've seen.

If you really want to go for this as an option, you could use code similar to that in Unconstrained Melody, a library I've got which exposes various methods with this hard-to-produce constraint. It uses IL rewriting, effectively - it's crude, but it works for UM and would probably work for you too. You'd probably want to put the interface into a separate assembly though, which would be somewhat awkward.

Of course, you could make your interface just have T : struct instead... it wouldn't be ideal, but it would at least constrain the type somewhat. So long as you could make sure it wasn't being abused, that would work reasonably well.

Jon Skeet
A: 

The inability to write public interface IError<T> where T: enum is something that we have all complained about for years. So far there has been no progress on that.

I usually end up writing public interface IError<T> and leaving a note for the implementor that T must be an enum.

Jonathan Allen
A: 

If I understand what you are wanting to do, then yes, there is no way to define an interface that contains as one of it's members a non-specific enum. Your second example is close, but you are limited to constraining the type of T to a struct, which would allow any value type. At that point, you just have to rely on the knowledge of the interfaces proper usage to let folks know the expected type of T should be an enum. You could potentially make it a little clearer by defining T as TEnum or TErrorValue:

public interface IError<TEnum> where T: struct
{
    T ErrorCode;
    string Description;
}
ckramer
+4  A: 

As Jon Skeet mentioned, the base IL supports constraining generics to be enums, however C# does not allow you to take advantage of it.

F# does allow this sort of constraint, however. Further, if the interface is defined in F#, the constraint will be enforced in C# code that implements the interface. If you're willing to mix languages in your solution, something like this should work just fine:

type IError<'T when 'T :> System.Enum and 'T : struct> =
    abstract member Error : 'T
    abstract member Description : string

If you put this in an F# project and reference it from your C# project, your C# code that implements the interface will cause a C# compiler error on any attempt to use it with a non-enum type.

Joel Mueller
How accessible is this solution to C# 2.0 and VS2005? I'm guessing...not very? While sounding pretty sweet, I'm not sure I'll be able to take advantage.
bwerks
Joel Mueller
T also needs to be constrained to be a value type, otherwise System.Enum would be okay.
Jon Skeet
@Jon - good point, I've updated the example accordingly.
Joel Mueller
Incidentally, F# allows you to be even more specific in your enum type constraints. If you only want to allow Int32-derived enums and not ones based on bytes or Int64, you can add this constraint: `and 'T : enum<int>`
Joel Mueller