views:

151

answers:

3

I have the following code:

interface IConverter<T, U>
{
    U Convert(T obj);
}

interface IBusinessEntityConveter<T, U> : IConverter<T, U>
    where U : BusinessEntity
{
}

class LookupConveter<B> : IBusinessEntityConveter<Lookup, B>, IConverter<Lookup, Moniker>
    where B : BusinessEntity, new()
{

    #region IConverter<Lookup, Moniker> Members

    public Moniker Convert(Lookup obj)
    {
       //...
    }

    #endregion


    #region IConverter<Lookup,B> Members

    public B Convert(Lookup obj)
    {
       //...
    }

    #endregion
}

I am getting this error:

Error 2 'Convertors.LookupConveter<B>' cannot implement both 'Convertors.IConverter<Microsoft.Crm.Sdk.Lookup,B>' and 'Convertors.IConverter<Microsoft.Crm.Sdk.Lookup,Microsoft.Crm.Sdk.Moniker>' because they may unify for some type parameter substitutions

Is there a way to specify that T isn't a business entity?

+2  A: 

No, there are no "negative" constraints.

Jon Skeet
How would you go around this unability to express resolvance of conflicgs?
the_drow
@the_drow: It's hard to say without knowing why you want the same type to convert generically and the specific type.
Jon Skeet
A lookup is a type/id tuple that represents a record in the database, converting it to a real type involves accessing a web service and fetching an xml file that is serialized to a DynamicEntity, I then convert the DynamicEntity (which is a BusinessEntity) to a home-coocked strong type. A lookup can also be converted to a moniker which is practically the same as a lookup but with less features and it is used somewhere else in the system and thus I would like to convert it easily. **This is not my code, it's Microsoft Dynamics CRM shitty architecture.** Only the converters are mine.
the_drow
@the_drow: Which bit is forcing you to implement both interfaces in the same class though?
Jon Skeet
Because they are related, I am trying to have this kind of syntax that could be injected with an IOC container: `IConverter<Lookup, Moniker> converter = new LookupConverter()`. You might be correct though, I just tried to stick with DRY principle. If only I could specialize a generic class...
the_drow
@Jon Skeet: Would you say that specifying that T is not U is an important feature? Should I go an ask for it in Microsoft Connect? Also got any idea to resolve this issue? Should I just go with separate classes?
the_drow
@the_drow: No, I don't think it's an important feature - it would add significant complexity with only very rare benefits, IMO. And yes, just go with separate classes.
Jon Skeet
+5  A: 

Nope, I'm afraid not. The only options you have are listed here Constraints on Type Parameters

Ian
A: 

I have been also trying to use explicit interfaces, as Stefan suggested, but it does not work. I assume IBusinessEntityConveter and IConverter are issuing two different concerns. I think you will have to split it and create two different IBusinessEntityConveters to fullfill both.

controlbreak
Did I said something wrong ? oO
controlbreak
Because this should be a commet!
the_drow
Hey I'm sorry, I just tried to help ! :D
controlbreak