Develop Reference

Interfaces, Inheritance, Implicit operators and type conversions, why is it this way?

I'm working with a class library called DDay ICal.
It is a C# wrapper for the iCalendar System implemented in Outlook Calendars, and many many many more systems.
My question is derived from some work I was doing with this system.
There are 3 objects in question here
IRecurrencePattern - Interface
RecurrencePattern - Implementation of IRecurrencePattern Interface
DbRecurPatt - Custom Class that has an implicit type operator
IRecurrencePattern: Not all code is shown
public interface IRecurrencePattern
{
string Data { get; set; }
}
RecurrencePattern: Not all code is shown
public class RecurrencePattern : IRecurrencePattern
{
public string Data { get; set; }
}
DbRecurPatt: Not all code is shown
public class DbRecurPatt
{
public string Name { get; set; }
public string Description { get; set; }
public static implicit operator RecurrencePattern(DbRecurPatt obj)
{
return new RecurrencePattern() { Data = $"{Name} - {Description}" };
}
}
The confusing part: Through out DDay.ICal system they are using ILists to contain a collection of Recurrence patterns for each event in the calendar, the custom class is used to fetch information from a database and then it is cast to the Recurrence Pattern through the implicit type conversion operator.
But in the code, I noticed it kept crashing when converting to the List<IRecurrencePattern> from a List<DbRecurPatt> I realized that I needed to convert to RecurrencePattern, then Convert to IRecurrencePattern (as there are other classes that implement IRecurrencePattern differently that are also included in the collection
var unsorted = new List<DbRecurPatt>{ new DbRecurPatt(), new DbRecurPatt() };
var sorted = unsorted.Select(t => (IRecurrencePattern)t);
The above code does not work, it throws an error on IRecurrencePattern.
var sorted = unsorted.Select(t => (IRecurrencePattern)(RecurrencePattern)t);
This does work tho, so the question I have is; Why does the first one not work?
(And is there a way to improve this method?)
I believe it might be because the implicit operator is on the RecurrencePattern object and not the interface, is this correct? (I'm new to interfaces and implicit operators)

You have basically asked the compiler to do this:
I have this: DbRecurPatt
I want this: IRecurrencePattern
Please figure out a way to get from point 1. to point 2.
The compiler, even though it may only have one choice, does not allow you to do this. The cast operator specifically says that DbRecurPatt can be converted to a RecurrencePattern, not to a IRecurrencePattern.
The compiler only checks if one of the two types involved specifies a rule on how to convert from one to the other, it does not allow intermediary steps.
Since no operator has been defined that allows DbRecurPatt to be converted directly to IRecurrencePattern, the compiler will compile this as a hard cast, reinterpreting the reference as a reference through an interface, which will fail at runtime.
So, the next question would be this: How can I then do this? And the answer is you can't.
The compiler does not allow you to define a user-defined conversion operator to or from an interface. A different question here on Stack Overflow has more information.
If you try to define such an operator:
public static implicit operator IRecurrencePattern(DbRecurPatt obj)
{
return new RecurrencePattern() { Data = $"{obj.Name} - {obj.Description}" };
}
The compiler will say this:
CS0552
'DbRecurPatt.implicit operator IRecurrencePattern(DbRecurPatt)': user-defined conversions to or from an interface are not allowed

Why does the first one not work?
Because you're asking the runtime for two implicit conversions - one to RecurrencePattern and one to IRecurrencePattern. The runtime will only look for a direct implicit relationship - it will not scan all possible routes to get you ask it to go. Suppose there were multiple implicit conversions to different types of classes that implement IRecurrencePattern. Which one would the runtime choose? Instead it forces you to specify individual casts.
This is documented in Section 6.4.3 of the C# Language specification:
Evaluation of a user-defined conversion never involves more than one
user-defined or lifted conversion operator. In other words, a
conversion from type S to type T will never first execute a
user-defined conversion from S to X and then execute a user-defined
conversion from X to T.

As others have pointed out already, you can't make a direct jump from DbRecurPatt to IRecurrencePattern. This is why you end up with this very ugly double cast:
var sorted = unsorted.Select(t => (IRecurrencePattern)(RecurrencePattern)t);
But, for completeness' sake, it should be mentioned that it is possible to go from a DbRecurPatt to a IRecurrencePattern without any casts with your current design. It's just that to do so, you need to split your expression into multiple statements, and by doing so, the code does become considerably uglier.
Still, it's good to know that you can do this without any casts:
var sorted = unsorted.Select( t => {
RecurrencePattern recurrencePattern = t; // no cast
IRecurrencePattern recurrencePatternInterface = recurrencePattern; // no cast here either
return recurrencePatternInterface;
});
EDIT
Credit to Bill Nadeau's answer for the idea. You can also benefit from implicit conversion and its compile time guarantees while keeping the code pretty elegant by writing it this way instead:
var sorted = unsorted
.Select<DbRecurPatt, RecurrencePattern>(t => t) // implicit conversion - no cast
.Select<RecurrencePattern, IRecurrencePattern>(t => t); // implicit conversion - no cast

There's another path to accomplish what you want. Specifically mark your generic arguments on your method calls instead of letting the compiler infer your generic arguments. You will still avoid casting, and it may be a little less verbose than some of the other options. The only caveat is you must include an additional Linq statement, which will resolve your list, if that matters.
var sorted = unsorted
.Select<DbRecurPatt, RecurrencePattern>(t => t)
.ToList<IRecurrencePattern>();
You could also combine this answer with sstan's to avoid the extra Linq statement.

... and to answer your final question about the implicit operator - no, you can't define an implicit operator on an interface. That topic is covered in more detail in this question:
implicit operator using interfaces

List<Type1> to List<Type2> conversion WPF [duplicate]

This question already has answers here:
Implicit Conversion over a Collection
(4 answers)
Closed 7 years ago.
I created simple type that contains only one dependency property "Text" returns string. For easy conversion from string to my type I wrote this code:
public static implicit operator string(StringDP sdp)
{
return sdp.Text;
}
public static implicit operator StringDP(string str)
{
return new StringDP(str);
}
I want to have similar conversion from List<string> to List<myType>. Am I able to do this? Or I have to use something like this:
public List<string> Convert(List<myType> lst);
public List<myType> Convert(List<string> lst);
Thank you!

No, this is not possible. From the documentation:
Either the type of the argument to be converted, or the type of the result of the conversion, but not both, must be the containing type.
Both of the types involved in your hypothetical implicit conversion are concrete versions of the generic List<T> class. Since you can't add operators to the List<T> class yourself, and since that's where the implicit operators to achieve your goal would have to be, it can't be done.
Without more context, I admit that I can't really comment knowledgeably on the implicit conversion to and from string that you've defined. But in general, you should be very careful with implicit conversions. Assuming the implicit conversion of your type fits within the "safe" guidelines, then a conversion of a whole list of the type would be "fine".
This conversion can be done with custom methods such as your examples. Or you can use LINQ or the List<T>.ConvertAll() method. E.g.:
List<string> listOfString = listOfMyType.Select(item => (string)item).ToList();
List<myType> listOfMyType = listOfString.ConvertAll(item => (myType)item);
// etc.
However, even there I would suggest that you should be careful about how you are using something like that. It's one thing to convert a single instance of a value, but converting a whole collection involves quite a lot more overhead and most likely is not the correct way to solve the problem.
Not know what the actual problem is, I can't offer an alternative. Just to suggest you be very wary of the design path you appear to be headed down.

Ambiguous call between overloads of two-way implicit castable types when a derived type of one is passed as parameter

(Trying to find a title that sums up a problem can be a very daunting task!)
I have the following classes with some overloaded methods that produce a call ambiguity compiler error:
public class MyClass
{
public static void OverloadedMethod(MyClass l) { }
public static void OverloadedMethod(MyCastableClass l) { }
//Try commenting this out separately from the next implicit operator.
//Comment out the resulting offending casts in Test() as well.
public static implicit operator MyCastableClass(MyClass l)
{
return new MyCastableClass();
}
//Try commenting this out separately from the previous implicit operator.
//Comment out the resulting offending casts in Test() as well.
public static implicit operator MyClass(MyCastableClass l)
{
return new MyClass();
}
static void Test()
{
MyDerivedClass derived = new MyDerivedClass();
MyClass class1 = new MyClass();
MyClass class2 = new MyDerivedClass();
MyClass class3 = new MyCastableClass();
MyCastableClass castableClass1 = new MyCastableClass();
MyCastableClass castableClass2 = new MyClass();
MyCastableClass castableClass3 = new MyDerivedClass();
OverloadedMethod(derived); //Ambiguous call between OverloadedMethod(MyClass l) and OverloadedMethod(MyCastableClass l)
OverloadedMethod(class1);
OverloadedMethod(class2);
OverloadedMethod(class3);
OverloadedMethod(castableClass1);
OverloadedMethod(castableClass2);
OverloadedMethod(castableClass3);
}
public class MyDerivedClass : MyClass { }
public class MyCastableClass { }
There are two very interesting things to note:
Commenting out any of the implicit operator methods removes the ambiguity.
Trying to rename the first method overload in VS will rename the first four calls in the Test() method!
This naturally poses two questions:
What it the logic behind the compiler error (i.e. how did the compiler arrive to an ambiguity)?
Is there anything wrong with this design? Intuitively there should be no ambiguity and the offending call should be resolved in the first method overload (OverloadedMethod(MyClass l, MyClass r)) as MyDerivedClass is more closely related to MyClass rather than the castable but otherwise irrelevant MyCastableClass. Furthermore VS refactoring seems to agree with this intuition.
EDIT:
After playing around with VS refactoring, I saw that VS matches the offending method call with the first overload that is defined in code whichever that is. So if we interchange the two overloads VS matches the offending call to the one with the MyCastableClass parameter. The questions are still valid though.

What it the logic behind the compiler error (i.e. how did the compiler arrive to an ambiguity)?
First we must determine what methods are in the method group. Clearly there are two methods in the method group.
Second, we must determine which of those two methods are applicable. That is, every argument is convertible implicitly to the corresponding parameter type. Clearly both methods are applicable.
Third, given that there is more than one applicable method, a unique best method must be determined. In the case where there are only two methods each with only one parameter, the rule is that the conversion from the argument to the parameter type of one must be better than to the other.
The rules for what makes one conversion better than another is in section 7.5.3.5 of the specification, which I quote here for your convenience:
Given a conversion C1 that converts from a type S to a type T1, and a conversion C2 that converts from a type S to a type T2, C1 is a better conversion than C2 if at least one of the following holds:
• An identity conversion exists from S to T1 but not from S to T2
• T1 is a better conversion target than T2
Given two different types T1 and T2, T1 is a better conversion target than T2 if at least one of the following holds:
• An implicit conversion from T1 to T2 exists, and no implicit conversion from T2 to T1 exists
The purpose of this rule is to determine which type is more specific. If every Banana is a Fruit but not every Fruit is a Banana, then Banana is more specific than Fruit.
• T1 is a signed integral type and T2 is an unsigned integral type.
Run down the list. Is there an identity conversion from MyDerivedClass to either MyCastableClass or MyClass? No. Is there an implicit conversion from MyClass to MyCastableClass but not an implicit conversion going the other way? No. There is no reason to suppose that either type is more specific than the other. Are either integral types? No.
Therefore there is nothing upon which to base the decision that one is better than the other, and therefore this is ambiguous.
Is there anything wrong with this design?
The question answers itself. You've found one of the problems.
Intuitively there should be no ambiguity and the offending call should be resolved in the first method overload as MyDerivedClass is more closely related to MyClass
Though that might be intuitive to you, the spec does not make a distinction in this case between a user-defined conversion and any other implicit conversion. However I note that your distiction does count in some rare cases; see my article for details. (Chained user-defined explicit conversions in C#)

What it the logic behind the compiler error?
Well, the compiler determines the signature based on a few things. The number and type of the parameters is next to the name, one of the most important ones. The compiler checks if a method call is ambiguous. It doesn't only use the actual type of the parameter, but also the types it can be implicitly casted to (note that explicit casts are out of the picture, they are not used here).
This gives the issue you describe.
Is there anything wrong with this design?
Yes. Ambiguous methods are a source of a lot of problems. Especially when using variable types, like dynamic. Even in this case, the compiler can't choose which method to call, and that is bad. We want software to be deterministic, and with this code, it can't be.
You didn't ask for it, but I guess the best option is:
To rethink your design. Do you really need the implicit casts? If so, why do you need two methods instead of one?
Use explicit casting instead of implicit casting, to make casting a deliberate choice a compiler can understand.

Implicit Vs explicit convers

I did an online assessment and I'm trying to understand the results, and here are a few of the questions I did already:
Get enum value from string
Change to method declaration
So the question is this:
I got this one partially right as well, after reading about the subject I would choose just option A and D, can you guys confirm?
Thanks a lot.
Marco

An implicit conversion does not need a cast:
int a = 10;
long b = a;
An explicit conversion does need a cast:
long a = 10;
int b = (int)a;
To define (not invoke) an implicit conversion, the implicit keyword is used:
public static implicit operator MyOther(MyThis obj);
To define an explicit conversion, the explicit keyword is used:
public static explicit operator MyOther(MyThis obj);
Usually, explicit conversions are used when information might be lost through the conversion, or an exception may occur. For example, converting a 64-bit long integer to a 32-bit int integer might lose the 32 most-significant bits of information.
So, I am sure A is true, B, C and E are false. I don't understand the question for D. If they mean invoking the implicit conversion, then it is false. If they mean defining the implicit conversion, then it is true.

Applying operators to non-mathematical objects?

I'm curious about how some operators work (+, -) in terms of objects.
I've always wondered how EventHandlers work by adding a method:
Foo.Action += new FooActionHandler
If not an Event, what about returning a comparison?
DateTime - DateTime
That returns a TimeSpan object, and I'm a bit baffled as to how that's possible. I use these kinds of methods all the time but I've never understood the inner workings of them. How would I create my own class to do something like this?

You can overload operators to perform whatever action you want. Here is some good documentation for how to do it in C#.
The gist of it is that you provide a context for the operator (your class) and what occurs with the parameters to it. A sample might look like this:
// Overload '+' for my class
public static MyClass operator +(MyClass c1, MyClass c2)
{
MyClass newMyClass = new MyClass();
newMyClass.MyIntProperty = c1.MyIntProperty + c2.MyIntProperty;
return newMyClass;
}

You can define operators like this:
public static MyClass operator +(MyClass a, MyClass b) { }
With the same syntax for -, *, etc.
Here are some tips (my opinion, mostly):
Don't put the actual logic in the operator - create a static method.
// NOT
public static MyClass operator +(MyClass a, MyClass b) { /* ... */ }
// YES
public static MyClass Add(MyClass a, MyClass b) { return new MyClass(a.Prop + b.Prop); }
public static MyClass operator +(MyClass a, MyClass b) { return Add(a, b); }
Don't bend the operators to do something they shouldn't - ie, don't use + to add to a list, or - to remove from a list, for example.
This causes two problems:
It isn't very well-regarded in the community
The compiler won't catch errors if you accidentally add two objects.

This is called operator overloading. Google will return many articles that explain how it works, and when to use and not use it.
http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=88

Here ya go: http://msdn.microsoft.com/en-us/library/aa288467(VS.71).aspx

It is called operator overloading. C# allows you to overload select operators.
There is more information on this here.

You can overload an operator to do whatever you want.
Lets say I have a Truck Class, and MachineGun class, I want to be able to do this:
Transformer myTransformer = mytruck + myGun;

the += and -= for EventHandlers are shortcuts for Delegate.Combine and Delegate.Remove, this is accomplished with operator overloading, see this site for more details.

This is known as operator overloading. It's used by the framework extensively, however you should avoid doing it since it can lead to some bad code if you don't know what you're doing.
Most programmers don't expect to see a custom class with operators being overloaded so it can become maintenance hell when other programmers have to look at your code and figure out what is going on.
Of course, there are situations where you may find it useful, but usually you're better off just using methods instead of creating operator overloads. You can find out more info from Microsoft here:
http://msdn.microsoft.com/en-us/library/aa288467.aspx

Plenty of answers have covered how you do it. Now just remember that you'll almost never want to actually do it yourself. You need to be really sure that anyone using your class will agree with you about what subtracting two MyClass objects means. If it represents some kind of mathematical structure (vector, matrix, etc) then you're probably safe. Otherwise, it's probably unclear. Notice that Microsoft defined subtraction for DateTime, but didn't allow
List<string> myList = new List<string>();
myList += "foo";
Any time you write
static Foo operator -( Foo a, Foo b )
then think about what you'd call that method if you couldn't override subtraction. If the best possible name isn't Subtract, then you probably want to just create a method with that other name.