Develop Reference

What does '=>' mean (in functions / property context)?

I got an auto generated code using Lambdas while developing a Xamarin application:
public override string this[int position] => throw new NotImplementedException();
public override int Count => throw new NotImplementedException();
What does the => operator mean in this context?
Thanks
R

These are not lambdas, they are Expression-bodied Members!
In the context of a property, these are basically the getters of a property simplified to become a single expression (as opposed to a whole statement).
This:
public override int Count => throw new NotImplementedException();
Is equivalent to:
public override int Count {
get { throw new NotImplementedException(); }
}

As #sweeper says in your example they do not relate to lambda expressions as they are expression body operators (which were introduced in C# 6 and expanded on in 7). It is also used to indicate a lambda expression though, so it's usage is two fold.
Further information on each usage of the => operator can be found here; https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/lambda-operator

First, let's clarify that the =>operator is currently used in two different contexts:
Lambda expressions.
Often you will see them in Linq, e.g.
var query = Customers.OrderBy(x => x.CompanyName);
Expression bodied functions. This is what we have here.
In order to understand what => means, please take a look at the following simple example:
using System;
public class Program
{
public void Main()
{
var obj = new Test();
obj.Count.Dump();
obj[7].Dump();
}
class Test
{
public int Count => 1;
public string this[int position] => $"2 x {position} = {(2*position)}";
}
}
Dumping object(Int32)
1
Dumping object(String)
2 x 7 = 14
Try it in DotNetFiddle
Here, the NotImplementedException code, which is just there to tell you (the developer) that the property and indexer is not implemented but should be, is replaced by some function:
Count is a readonly property returning always 1
whenever you apply [ ... ] to the object, the doubled index is returned
Note that in earlier versions of C# you had to write:
class Test
{
public int Count { get { return 1; } }
public string this[int position] {
get { return String.Format("2 x {0} = {1}",
position, (2*position).ToString()); }}
}
which is equivalent to the code above. So in essence in C#7 you have to type much less to achieve the same result.

Mathematics and generics

Ok, I need to implement, among others, these two particular types: ComplexNumber<T> and Matrix<T>. T can be one of the following: a rational number, a real number or integers.
In the System namespace I have a good representation for real numbers (decimal), integer numbers (int or long). Numerics.ComplexNumber does not cut it becuase internally RealPart and ImaginaryPart are double and I can't afford, in this particular case, the representation error of this type.
Now, the probem is of course that there is no way to constraint the generic parameter T to mathematical "valid" types. That is, I can't do the following:
public struct ComplexNumber<T>
{
readonly T realPart;
readonly T imaginaryPart;
public static ComplexNumber<T> Add(ComplexNumber<T> left, ComplexNumber<T> right)
{
return new ComplexNumber<T>(left.realPart + right.realPart, left.imaginaryPart + right.imaginaryPart); //Compile time error. No operator defined for T
}
}
So I need a workaround. Although performance is not a goal in itself, I'd like the code to work reasonably well, but above all, I'd like it to be the most elegant solution possible. Right now I've come up with two possibilities:
A Numeric abstract base class similar to:
public abstract class Numeric
{
protected abstract Numeric _Add(Numeric right);
protected abstract Numeric _Subtract(Numeric right);
public static Numeric Add(Numeric left, Numeric right) { return _Add(this, right); }
public static Numeric Subtract(Numeric left, Numeric right) { return _Subtract(this, right);
}
Now I could do:
public sealed class RationalNumber: Numeric
{
readonly long numerator, denominator;
protected override Numeric _Add(Numeric right) { //Rational addition implementation }
}
And then Matrix<RationalNumber> or Matrix<ComplexNumber> would work.
The other option is to do it through an interface:
public INumeric
{
INumeric Add(INumeric right);
INumeric Subtract(INumeric right);
}
public struct RationalNumber: INumeric
{
readonly long numerator, denominator;
public static RationalNumber Add(RationalNumber left, RationalNumber right) { //Rationa add implementation }
INumeric INumeric.Add(INumeric right) //explicit to not clog up the type and to convey the idea of a framework mechanism.
{
if (!(right is RationalNumber))
throw new ArgumentException();
Add(this, (RationalNumber)right);
}
The interface option lets me implement RationalNumber as a struct wich is, IMHO, more consistent with how numeric types are implemented in the framework. Also the types themselves are pretty lightweight and will typically have short lives. The Numeric base class solution seems like a whole lot more heavyweight, but I'm not really an expert to exactly quantify the advantages of one over the other when it comes to:
Code qualitiy and future extensibility and maintenance
Performance and memory consumption (curiosity more than anything else)
A better solution?
If anyone can shed a little bit of light, I'd appreciate it.

You can use extensions method to solve this problem:
public struct ComplexNumber<T>
{
private readonly T _realPart;
private readonly T _imaginaryPart;
public ComplexNumber(T realPart, T imaginaryPart)
{
_realPart = realPart;
_imaginaryPart = imaginaryPart;
}
public T RealPart
{
get
{
return _realPart;
}
}
public T ImaginaryPart
{
get
{
return _imaginaryPart;
}
}
public override string ToString()
{
return string.Format("({0}, {1})", RealPart, ImaginaryPart);
}
}
public static class ComplexNumberExtensions
{
public static ComplexNumber<int> Add(this ComplexNumber<int> self, ComplexNumber<int> other)
{
return new ComplexNumber<int>(self.RealPart + other.RealPart, self.ImaginaryPart + other.ImaginaryPart);
}
public static ComplexNumber<double> Add(this ComplexNumber<double> self, ComplexNumber<double> other)
{
return new ComplexNumber<double>(self.RealPart + other.RealPart, self.ImaginaryPart + other.ImaginaryPart);
}
// Add similar extension methods for each numeric type you need
}
Use it like this:
var first = new ComplexNumber<int>(1, 2);
var second = new ComplexNumber<int>(3, 4);
var result = first.Add(second);
Console.WriteLine(result);

Properly implement comparison of two objects with different type but semantically equivalent

I've found a similar question
How to compare two distinctly different objects with similar properties
that may implicitly and/or in part reply to my question.
Suppose I want compare (without a lot of nested conditions) this object:
class ObjectA {
public string PropertyX { get; set; }
public char PropertyY { get; set; }
public long PropertyZ { get; set; }
}
to a System.String. I'm interested only in equality or inequality (not a range of values about identity).
Implementing IEquatable<string> in ObjectA is a proper choice? I don't care of what simply works, I want to identify the proper pattern for such case.
As other information, please consider that ObjectA will often be supplied as sequence of IEnumerable<ObjectA>.
I don't need to know if "string" == or != objectA instance; sorting is not involved.
Edit to clarify (and help)
Sorry but writing a good question is sometime difficult...
Suppose I can't represent ObjectA as string for the purpose of comparison (violating encapsulation is not an option).
In context-1 I've to match it against PropertyY.
In context-2 I've to match it against an algorithm applied to PropertyY/PropertyZ.
#Oliver solution in the end of the question helps me again (and +1 again).
I can simply define a custom interface:
interface IContextConverter {
string ToEquatableStringForContext1();
string ToEquatableStringForContext2();
}
Since I've also an ObjectB with same logic but different properties, both will implement IContextConverter (or maybe I find a better name) avoiding to violate RAP.

I would strongly recommend to not implement IEquatable<string>, cause especially when working with collections, dictionaries, LINQ, etc. you don't really know when one of these methods will be called somewhere deep inside which leads maybe to subtle bugs.
Due to the fact that you like to compare two objects of different types a simple Comparer<T> wouldn't work also.
So either write a TypeConverter which converts your object into the desired type (in your case a string) or add a method to your object like .ToEquatableString() and use their output to compare your object with the other string.
Here is an example on you could get all elements, that match one of a string in another collection:
IEnumerable<String> otherElements = new[] {"abc", "def", "ghi" };
IEnumerable<ObjectA> myObjects = GetObjects();
var matchesFound = otherElements.Join( // Take the first collection.
myObjects, // Take the second collection.
s => s, // Use the elements in the first collection as key (the string).
obj => obj.ToEquatableString(), // Create a string from each object for comparison.
(s, obj) => obj, // From the matching pairs take simply the objects found.
StringComparer.OrdinalIgnoreCase); // Use a special string comparer if desired.

There are many possibilities.
If you feel an ObjectA is a kind of System.String, you could write a user-defined conversion (implicit or explicit) from ObjectA to System.String, or from System.String to ObjectA, or both directions.
You could also overload the == and != operators with a signature like operator ==(ObjectA oa, string s). Beware that there is difference between oa == s and s == oa.
Either of these two possibilities may lead to confusion. It would also be confusing to override the virtual Equals(object), or to introduce an overload Equals(string). Therefore I don't recommend implementing IEquatable<string>.
Why not simply write a method with an unused name, like public bool EqualsString(string s)? Then you will have to call this method explicitly, of course, but that will lead to less confusion. Another idea would be to use a constructor of signature public ObjectA(string s) and then implement "homogeneous" equality of ObjectA and ObjectA.

NOTE: I do not particulary recommend this solution for this particular case, but I have often used this framework to implement Value Equality for structs. Difficult trade-offs are common in our field, and answers that address those, accompanied by appropriate caveats, seem in order.
I take it that you wish to design Value Equality semamtics on your class in the same fashion as the .NET framework does this for the string class. At a minimum, the following is necessary:
public override bool Equals(object obj) {
return (obj is ObjectA) && this == (ObjectA)obj;
}
bool IEquatable<ObjectA>.Equals(ObjectA rhs) {
return this == rhs;
}
public static bool operator != (ObjectA lhs, ObjectA rhs) {
return ! (lhs == rhs);
}
public static bool operator == (ObjectA lhs, ObjectA rhs) {
return (lhs.PropertyX == rhs.PropertyX);
}
public override int GetHashCode() {
return PropertyX.GetHashCode()
}
Expanding to allow Value comparisons beween ObjectA and string:
bool IEquatable<ObjectA>.Equals(string rhs) {
return this == rhs;
}
public static bool operator != (ObjectA lhs, string rhs) {
return ! (lhs == rhs);
}
public static bool operator != (string lhs, ObjectA rhs) {
return ! (lhs == rhs);
}
public static bool operator == (ObjectA lhs, string rhs) {
return (lhs.PropertyX == rhs);
}
public static bool operator == (string lhs, ObjectA rhs) {
return (lhs == rhs.PropertyX);
}

Operators and inheritance

My brain has turned to jelly, or I'm having an out of mind experience, or something. I'm tinkering with a class hierarchy that looks a bit like this:
My Money class looks like this:
public abstract class Money
{
public int Amount { get; set; }
public static bool operator ==(Money leftSide, Money rightSide)
{
// Money can only be equal if it is in the same currency.
if (leftSide.GetType() != rightSide.GetType()) return false;
return leftSide.Amount == rightSide.Amount;
}
public static bool operator !=(Money leftSide, Money rightSide)
{
// If the currencies are different, the amounts are always considered unequal.
if (leftSide.GetType() != rightSide.GetType()) return true;
return leftSide.Amount != rightSide.Amount;
}
public static Money operator *(Money multiplicand, int multiplier)
{
var result = multiplicand * multiplier;
return result;
}
public static Dollar Dollar(int amount)
{
return new Dollar(amount);
}
public static Franc Franc(int amount)
{
return new Franc(amount);
}
}
My Dollar operator * looks like this:
public static Dollar operator *(Dollar multiplicand, int multiplier)
{
var result = multiplicand.Amount * multiplier;
return new Dollar(result);
}
Now, if I run this test code, I get a Stack overflow (wahoo!)
{
Money fiveDollars = Money.Dollar(5);
Money timesTwo = fiveDollars*2;
}
I had expected that this would recursively call the subclass (Dollar) operator *, which would return a definite result since (Dollar * int) is defined non-recursively. Since this doesn't work, the alternative is that I have done something dumb. Why doesn't this work? What would be the right way to get this behaviour?

You seem to have left out .Amount
public static Money operator *(Money multiplicand, int multiplier)
{
var result = multiplicand.Amount * multiplier;
return result;
}

The problem is that you expect that you can override operators in derived classes and expect dynamic binding. This is not the way it works in C#. Operators are overloaded and the actual overload is chosen compile-time. This means that the following code is recursive and calls itself:
public static Money operator *(Money multiplicand, int multiplier)
{
var result = multiplicand * multiplier;
return result;
}
Another example where you can see the difference between operator overloading and method overriding is this:
int a = 5;
int b = 5;
Console.WriteLine(a == b); // true
Console.WriteLine(a.Equals(b)); // true
Console.WriteLine((object)a == (object)b); // false
Console.WriteLine(((object)a).Equals((object)b)); // true
In the third case, C# treats a and b as objects instead of integers, so it uses the default == operator that is used for objects: comparing references (in this case the references of boxed integers).
This can make it awkward to define operators on a class hierarchy where you want to redefine the operators in derived classes. It is especially awkward when the behavior depends on the combination of both operands, since C# (and most other OOP languages) lacks support for multiple dispatch. You can solve this by using the visitor pattern, but I think in this case you should reconsider if using subclasses for each currency is the best solution.

Confirming Greenspun's 10th Law in C#

I am trying to implement an infrastructure in C# that would allow me to make arbitrary mathematical expressions. For example, I want to be able to take an expression like
asin(sqrt(z - sin(x+y)^2))
and turn it into an object that will allow me to evaluate it in terms of x,y, and z, get derivatives, and possibly do some kind of symbolic algebra on it. What are people's thoughts on a good model for this in C#?
I have my own take, which I am afraid is heading off into architecture astronautics, so I want to make sure that is not the case.
Basically, the functions like sin, +, sqrt, etc. have classes based off a base class:
Function
Function<TOut> : Function
TOut Value
Function<Tin, TOut> : Function
TOut Evaluate(TIn value)
Function Derivative
Function<TOut, TIn> INverse
Function<TInA, TInB, TOut> : Function
TOut Evaluate(TInA valueA, TInB valueB)
Function PartialDerivativeA
Function PartialDerivativeB
So far, so simple. The trick is how to compose the functions. Here I believe I want something like a currying approach so that I can evaluate the function for a single parameter, and have the other ones remain. So I am thinking of having a factory class like this:
Function<TInA, TInB, TOut> ->
Function<TInA, Function<TInB, TOut>>
(Function<TInA, TInB, TOut>, Function<TInX, TInA>, null) ->
Function<TInX, Function<TInB, TOut>>
(Function<TInA, TInB, TOut>, Function<TInA>, Function<TInX, TInY, TInB>) ->
Function<TInX, Function<TInY, TInB>>
and so on. My main concerns are that the generic types might make the system unusable (if the user is required to know the full generic types just to evaluate), and that I might not be able to construct all of the generic types from the input arguments.
Thanks for your input!

Note that it is possible to use the C# compiler to evaluate expressions.
Evaluating Mathematical Expressions by Compiling C# Code at Runtime
http://www.codeproject.com/KB/recipes/matheval.aspx

What about using Expression Trees? Note that on the linked page, there's even an example for building sort of a curried function (building a "less than five" function from a generic "less than" operator and a fixed constant)

I'm not entirely sure what currying is, but the usual approach to parsing expressions is to build an abstract syntax tree.
From this it shouldn't be difficult to evalute the expression, find the derivative, or whatever it is you want to do.
[Edit] I'm afraid your comments make no sense. From the sounds of it, you want to parse an expression and build an AST, from which you can do whatever you want with it. Yes, you will build classes for each type of node; something like this
public class PlusNode : BinaryNode
{
public PlusNode(Node left, Node right) { base(left, right); }
public virtual double Evaluate() { return Left.Evaluate() + Right.Evaluate(); }
public virtual Node BuildDerivative()
{
return new PlusNode(Left.BuildDerivative(), Right.BuildDerivative());
}
}
public class SinNode : UnaryNode
{
public SinNode(Node child) { base(child); }
public virtual double Evaluate() { return Math.Sin(Child.Evaluate()); }
public virtual Node BuildDerivative()
{
return new MultiplyNode(new CosNode(Child.Clone()), Child.BuildDerivative()); //chain rule
}
}

Funny, I actually did this a few months ago in D and it wasn't received as particularly interesting. My approach was to use templated expression tree classes. I had a Binary class template that could be instantiated with +, *, etc, a unary class that could be instantiated with sin, exp, etc. Derivatives worked by mostly just recursively applying the chain and product rules. For example:
class Binary(alias fun) : MathExpression {
MathExpression left, right;
MathExpression derivative() {
static if(is(fun == add)) {
return left.derivative + right.derivative;
} else static if(is(fun == mul)) {
return left.derivative * right + right.derivative * left;
}
}
real opCall(real x) {
return fun(left(x), right(x));
}
}
class Unary(alias fun) : MathExpression {
MathExpression inner;
MathExpression derivative() {
static if(is(fun == sin)) {
return Unary!(sin)(inner.derivative);
}
}
real opCall(real x) {
return fun(inner(x));
}
}
class Constant : MathExpression {
real val;
real opCall(real x) {
return val;
}
real derivative() {
return new Constant(0);
}
}