none
Constraints/Generics - can you constrain a type parameter to be inequal to another? RRS feed

  • Question

  • I am trying to make a class the pretends to be one of two classes (it can hold parameters for either). Basically I want to have an easy way to have a dictionary that can use one of two types for a key, without having to rewrite the dictionary class, or a good chunk of it. (i.e. string or type, string or int, etc).

    My thought was:

    • A generic class that can hold a value of one of two types.
    • It should produce the GetHasCode() result of the stored variable
    • It should be able to compare the stored value with either templated type
    • It should be able to check for equality between the stored variable and another variable.

    I have tried the following:

        class DualType<T1, T2> : IComparable, IComparable<T1>, IComparable<T2>, IComparable<DualType<T1,T2>>, ICloneable, IEquatable<DualType<T1, T2>>
            where T1 : class, IComparable
            where T2 : class, IComparable
        { /*...*/ }

    The following errors/warnings are produced on compile attempts:

    Error    3    Duplicate user-defined conversion in type 'SjssDataLib.DualType<T1,T2>'    C:\Users\sjss\documents\visual studio 2010\Projects\SjssDataLib\SjssDataLib\DualType.cs    104    23    SjssDataLib
    Error    4    Duplicate user-defined conversion in type 'SjssDataLib.DualType<T1,T2>'    C:\Users\sjss\documents\visual studio 2010\Projects\SjssDataLib\SjssDataLib\DualType.cs    116    23    SjssDataLib

    Error    3    'SjssDataLib.DualType<T1,T2>' cannot implement both 'System.IComparable<T1>' and 'System.IComparable<T2>' because they may unify for some type parameter substitutions    C:\Users\sjss\documents\visual studio 2010\Projects\SjssDataLib\SjssDataLib\DualType.cs    16    11    SjssDataLib


    I suspect, if I could convince the compiler that T1 and T2 cannot be the same, then the problem will go away, but there doesn't appear to be a way to do this. Any other option I can think of, would either require a lot of extra calculations (typechecking in several calculations), or produce the same errors. Are there any other options?



    Imagine a great looking signature here.

    Saturday, September 22, 2012 11:30 PM

Answers

  • Would it work if you don't implement either of the IComparable<>'s?  The one that you don't implement can still be done via the non-generic interface IComparable.  See if you can get away with it like this.

    Jose R. MCP
    Code Samples

    • Marked as answer by Jim Stapleton Sunday, September 23, 2012 12:19 PM
    Sunday, September 23, 2012 2:55 AM

All replies

  • Would it work if you don't implement either of the IComparable<>'s?  The one that you don't implement can still be done via the non-generic interface IComparable.  See if you can get away with it like this.

    Jose R. MCP
    Code Samples

    • Marked as answer by Jim Stapleton Sunday, September 23, 2012 12:19 PM
    Sunday, September 23, 2012 2:55 AM
  • Is it not that a Collection object by definition holds similar types of objects? Of course, "similar" does not necessarily mean "same". To be specific, it means all the objects that are to be enrolled into a Collection normally inherit a common class or implement a common interface.

    If you satisfy this normal behavior, then there is no need to implement IComparable twice. It will be easy to apply the refactoring "Pull Up Method" in that case then.

    Sunday, September 23, 2012 10:19 AM
  • WebJose - wow. I should have thought of that. Some times I'm so focused on being thorough I forget that it isn't always needed.


    Rajesh - It's not exactly a collection object. This will only hold /one/ value at a time, of type T1 or type T2. If you set T1=T2, then you might as well use an object of that type. The only purpose of this is really to have a dictionary that can have a key of either of two types - and no other types, without having to do a lot of overriding or rewriting of existing dictionary functionality. I don't believe the comparisons are explicitly necessary, but they will probably be useful for other things later on.


    Imagine a great looking signature here.

    Sunday, September 23, 2012 12:22 PM