I recently discovered the wonders of implicit operator overloading in C#. I was wondering, if you have both "ways" of implicit operator overloading, such as:
public static implicit operator FooType(int num)
{
return new FooType(num);
}
public static implicit operator int(FooType fooType)
{
return fooType.IntValue;
}
Is there a name for that design pattern?
Is there a predefined .NET interface that I can use, say ICastable<int>?
Not that I'm aware of.
You might consider implementing IConvertible. (If your class can also be compared to things, you might consider implementing IComparable<T>.)
If it is i have never heard of it
Operators are static constructs and are resolved at compile time. They cannot be part of any interface
Related
I have several implicit conversion operator overloads and they're all using exactly the same code. How would I go about refactoring it?
I would like the flexibility of being able to add more implicit operator overloads without needing to change the class everytime.
I tried to think of a design pattern that might come in handy. Builder or Strategy came to mind but I'm not sure about it.
Note: the Binary.ToBitArray() has 3 method overloads - one that takes a string parameter, one that takes an int parameter and one that takes a long parameter. That's how I'm able to use the same code.
public static implicit operator Register(string binaryNumber)
{
//Converting binaryNumber into a BitArray
BitArray registerBits = Binary.ToBitArray(binaryNumber);
return new Register(registerBits);
}
public static implicit operator Register(int binaryNumber)
{
//Converting binaryNumber into a BitArray
BitArray registerBits = Binary.ToBitArray(binaryNumber);
return new Register(registerBits);
}
public static implicit operator Register(long binaryNumber)
{
//Converting binaryNumber into a BitArray
BitArray registerBits = Binary.ToBitArray(binaryNumber);
return new Register(registerBits);
}
Syntactically the code is the same, but you're actually calling three different functions in your methods.
You could use dynamic to defer the binding until runtime, but this exposes some risks:
Your code is no longer type-safe. Callers have no idea what types are valid as parameters
Bugs are not discoverable at compile-time. Someone else could call your implicit operator on, say, a boolean, and you wouldn't know anything was wrong until runtime.
IMHO the potential risks are not worth saving a little bit of (mostly) duplicate code.
I have a generic class, MyClass<T>, and I want to be able to implicitly convert from some type, e.g. bool, to a specific version of the generic type, e.g. MyClass<string>. It seems I cannot use any of the following:
fails because "Using the generic type 'MyClass<T>' requires '1' type argument(s)":
public static implicit operator MyClass(bool value) {
return new MyClass<string>(value.ToString());
}
fails because "Unbound generic name is not valid in this context" and because "User-defined conversion must convert to or from the enclosing type":
public static implicit operator MyClass<>(bool value) {
return new MyClass<string>(value.ToString());
}
fails because "User-defined conversion must convert to or from the enclosing type":
public static implicit operator MyClass<string>(bool value) {
return new MyClass<string>(value.ToString());
}
fails because "Cannot implicitly convert type 'MyClass<string>' to 'MyClass<T>'":
public static implicit operator MyClass<T>(bool value) {
return new MyClass<string>(value.ToString());
}
Is there any way this can be achieved, or will I just have to live without it (and incur explicit calls to a conversion method everywhere)?
No, you can't do this. The C# specification is clear, your implicit operator must convert either to or from the type in which it's declared. It has to be an exact conversion, and since the declaring type is exactly MyClass<T>, the conversion has to be either to or from that.
See e.g. Can i use a generic implicit or explicit operator? C# and C# Implicit operator with generic.
At the risk of condoning or endorsing an XY Problem, here are a couple of hacky alternatives:
// Break generics by checking the type explicitly. Requires ugly casting
// and intermediate boxing, though it's possible that with some run-time
// use of Expressions, you could cache a delegate that would handle the
// conversion without the boxing. It'd still be ugly though.
class Class1<T>
{
public Class1(T t) { }
public static implicit operator Class1<T>(bool value)
{
if (typeof(T) == typeof(string))
{
return (Class1<T>)(object)(Class1OfString)value;
}
throw new InvalidOperationException("Invalid type T");
}
}
// Subclass the generic, and declare the conversion there. Of course, then
// to use the conversion, you have to reference this type explicitly. Ugly.
class Class1OfString : Class1<string>
{
public Class1OfString(string text) : base(text) { }
public static implicit operator Class1OfString(bool value)
{
return new Class1OfString(value.ToString());
}
}
class A
{
public static void M()
{
// These all compile and execute fine
Class1OfString c1 = true;
Class1<string> c2 = (Class1OfString)true;
Class1<string> c3 = true;
}
}
There are a number of variations on the themes above, but they all will involve circumventing and special casing the type in some way.
It is worth pointing out that, besides the difficulty dealing with the generic vs. specific here, the use of implicit is suspect for other reasons. The documentation states right at the top that one should use implicit only "if the conversion is guaranteed not to cause a loss of data" and implementations "should never throw exceptions". In both cases, this is "so that they can be used safely without the programmer's awareness". In other words, the very nature of implicit is that they get invoked implicitly, without the programmer necessarily even thinking about it. So they must always work, which wouldn't necessarily be the case with some of the examples above (and in one example, you have to use an explicit syntax anyway, so you might as well implement the operator as explicit anyway).
None of these options are ideal. But frankly, neither is the original scenario. It is odd for a generic type to have to deal with concrete types on a specific basis. It calls into question whether the generic type really should be generic in the first place. It is possible that you really should be doing something more like the subclassing example above, only applied further. I.e. use the generic type for whatever base behavior you need, but put all your specializations into a subclass where you know the type parameter T.
I can't offer more advice than that, given the lack of details in the question. But the basic request is shaky enough to suggest that, if only the question had included a broader problem statement and details about what led you to this actual implementation goal, a better and more applicable answer might have been provided.
Say I have a simple object which supports implicit casting to System.String
public sealed class CompanyCode
{
public CompanyCode(String value)
{
{ Regex validation on value format }
_value = value;
}
readonly String _value;
public override String ToString() => _value;
static public implicit operator String(CompanyCode code) =>
code?.ToString();
}
Now lets say in another part of my program I perform a comparison with a string:
var companyCode = { some company code object }
if (companyCode == "MSFTUKCAMBS")
// do something...
What is the compiler doing with the == operator? Is it implicitly casting companyCode to a string and running the System.String == implementation? Is it using the System.Object == implementation? Or will the compiler just complain at me? (I don't have a compiler to check this right now).
As far as I can see I have a couple of other options.
Implement an ==(String x) operator on CompanyCode.
Implement the IEquatable<String> interface on CompanyCode.
Would any (or both) of these options be preferable?
Say I have a simple object which supports implicit casting to System.String
I would question this design decision to start with. The fact that it's brought up this question of operator overloading suggests that your colleagues will be asking the same sort of questions. I don't even know the answer (in terms of what the compiler will do) off the top of my head.
I definitely wouldn't suggest implementing IEquatable<string>, as then x.Equals(y) won't be symmetric with y.Equals(x). You could implement two overloads of == in your class, both ways round... but then it wouldn't be consistent with Equals.
I would suggest just having a property called Value or Code of type string, then you can use:
if (companyCode.Value == "MSFTUKCAMBS")
and it will be immediately clear what that means.
Basically, I think the situations where implicit conversions are appropriate are very few and far between.
From the Design Guidelines for Class Library Developers
Do not provide a conversion operator if such conversion is not clearly expected by the end users.
Is there such a clear expectation here?
It will implicitly cast to a string and check equality using the string's == operator.
For the case you show - every way you offered is suitable, but every way has a different purpose and meaning.
Implicitly conversion should usually be avoided.
Implementing the == is to allow comparing with a string,
and IEquatable is simply to allow using the class as type IEquatable, for outside code references. The IEquatable may very well just return the == result.
For this case, I would choose the == operator overloading, unless you have any other purpose for using implicit conversion.
Also, if you use implicit conversions, it will be a bit uglier code-wise but smarter robust-wise to overload an EXPLICIT conversion, and not an implicit one, so whenever one wants to convert your class to a string, he will have to cast it using (string)obj, which is also a good reminder for whats really happening in the code.
I personally would suggest do not use operator overloading, in these cases. It's kind of confusing looking on the code, to understand what is going on.
It's a much better, imo, having some function that esplicitly manifests comparison operation, or, like Jon suggests, use a property.
In short make it clear for the reader of your code what you're gonna to compare.
I have gone to an interview where I was asked to answer a question:
Is operator overriding supported by C#?
I know that operator overloading is supported but I have no idea about overriding a operator. Is it possible?
No, operator overriding is not supported. The term Overriding is used when a method is inherited by a subclass and the subclass overrides it with its own implementation. Operators are all static in C# and cannot be overridden.
Overloading means that another method with the same name but a different signature (arguments) is defined. That's what you can do with operators.
This is extremely important to know when writing operators in C#. The operator is bound at compile time. The effective type which is passed to the operator at runtime is not important at all.
Eg. you write some comparison operator
public static bool operator==(MyClass c1, MyClass c2)
{
//...
}
And have the following code:
object myObj1 = new MyClass();
object myObj2 = new MyClass();
if (myObj1 == myObj2)
//...
object's operator will be called, not your own, because the
arguments are references of type object.
Is this valid?
public struct MyStruct
{
public int Foo { get; set; }
public static bool operator ==(MyStruct a, MyStruct b)
{
return a.Equals(b);
}
public static bool operator !=(MyStruct a, MyStruct b)
{
return !a.Equals(b);
}
}
(I know it's slightly inefficient because Object.Equals uses reflection for value types by default. But is it valid?)
I'm asking because ReSharper highlights it and warns me that MyStruct defines operator '==' or operator '!=' but does not provide 'Object.Equals(object o)' and 'Object.GetHashCode()'.
I think this may be interesting.
Valid? Yes. But it doesn't buy you anything.
It's valid, in terms of the fact that it compiles. But it's "invalid" in the sense that it breaks all expectations of users of your class - the framework design guidelines specify that you shouldn't implement functionality that only exists in operator overloads - that such methods should be accessible in other ways. And the standard is that Object.Equals and operator== implement the same functionality.
(Can only find the 1.1 version of the guidelines at the moment):
Provide alternate signatures. Most
languages do not support operator
overloading. For this reason, it is a
CLS requirement for all types that
overload operators to include a
secondary method with an appropriate
domain-specific name that provides the
equivalent functionality. It is a
Common Language Specification (CLS)
requirement to provide this secondary
method. The following example is
CLS-compliant.