I have class like bellow and I want to only let x be changed in Foo method and no other property. I can't use [Pure] like following example, because it locks all properties:
public class Test
{
private int x,y,z; //number of these properties is large
[Pure]
public void Foo()
{
//only x must be allowed to change
}
}
and I don't want to use something like this for all other properties than x:
Contract.Ensures(Contract.OldValue<int>(y) == y);
Contract.Ensures(Contract.OldValue<int>(z) == z);
...//and for other large number of properties
Is there any way to do this?
Unfortunately, standard way with Contracts I'm not found.
But you may use this way (this way have some constraints):
public class Test
{
public int x, y, z;//....
public void Foo()
{
x = FooBody();
}
[Pure]
private int FooBody()
{
int value = x;
//work with value as x
return value;
}
}
It seems there is no method implemented for this purpose in Contract class.
Related
from this reference : http://functionalprogrammingcsharp.com/honest-functions
I have learned to be more honest when defining method/function in C#.
It said that prefer pure function so that the function will always give the exact return type given in signature.
However when I try to apply it:
int Divide(int x, int y)
{
return x / y;
}
From the website:
The signature states that the function accepts two integers and returns another integer. But this is not the case in all scenarios. What happens if we invoke the function like Divide(1, 0)? The function implementation doesn't abide by its signature, throwing DivideByZero exception. That means this function is also "dishonest". How can we make this function an honest one? We can change the type of the y parameter (NonZeroInteger is a custom type which can contain any integer except zero):
int Divide(int x, NonZeroInteger y)
{
return x / y.Value;
}
I'm not sure what is the implementation of NonZeroInteger, they don't seem to give any implementation of NonZeroInteger in the website, should it check for 0 inside that class? And
I'm pretty sure if I call Divide(1, null) it will still show an error, thus making the function not honest.
Why honest function example in C# still not being honest?
Taking the example you've posted, and having read the link, if you want to make the function "honest" then you don't really need to create a new type, you could just implement the Try pattern:
bool TryDivide(int x, int y, out int result)
{
if(y != 0)
{
result = x / y;
return true;
}
result = 0;
return false;
}
This function basically fulfills the "honest" principle. The name says it will try to do division, and the resulting 'bool` says that it will indicate it is was successful.
You could create a struct NonZeroInteger but you're going to have to write a lot of code around it to make it act like a regular numeric type, and you'll probably come full circle. For example, what if you pass 0 to the NonZeroInteger constructor? Should it fail? Is that honest.
Also, struct type always have a default constructor, so if you're wrapping an int it's going to be awkward to avoid it being set to 0.
To make it honest, define a new data structure and check the status.
enum Status { OK, NAN }
class Data
{
public int Value { get; set; }
public Status Status { get; set; }
public static Data operator /(Data l, Data r)
{
if (r.Value == 0)
{
// Value can be set to any number, here I choose 0.
return new Data { Value = 0, Status = Status.NAN };
}
return new Data { Value = l.Value / r.Value, Status = Status.OK };
}
public override string ToString()
{
return $"Value: {Value}, Status: {Enum.GetName(Status.GetType(), Status)}";
}
}
class Test
{
static Data Divide(Data left, Data right)
{
return left / right;
}
static void Main()
{
Data left = new Data { Value = 1 };
Data right = new Data { Value = 0 };
Data output = Divide(left, right);
Console.WriteLine(output);
}
}
The notion of "honest function" still has room for interpretation, and I don't want to debate about it here, would be more opinion than actual useful answer.
To specifically answer your example, you could declare NonZeroInteger as a ValueType, with struct instead of class.
A value type is non-nullable (except if you explicitly specify the nullable version with a ?). No null-problem in this case. By the way, int is an example of value type (it's an alias for System.Int32, to be exact).
As some have pointed out, it could lead to other difficulties (struct has always a default constructor that initialize all fields to their default, and the default for an int is 0...)
For an mid-experienced programmer, this kind of example does not need to be explicitly implemented in the article to be understood on principle.
However, if you are unsure about it, it would definitely be a good programming learning exercise, I strongly encourage you to implement it yourself! (And create unit tests to demonstrate that your function has no "bug", by the way)
This NonZeroInteger is just a "symbol", which just represents the idea, not conrete implementation.
Surely, author could provide implemenetation of such construct, but its name servers just right for the sake of an article.
Possible implememntation might be:
public class NonZeroInteger
{
public int Value { get; set; }
public NonZeroInteger(int value)
{
if( value == 0 ) throw new ArgumentException("Argument passed is zero!");
Value = value;
}
}
But it's just pushing dishonesty somewhere else (in terms of an article), because constructor should return an object, not throw exception.
IMO, honesty is not achievable, because it's just moving dishonesty somewhere else, as shown in this example.
After reading it thoroughly a lot of times..
I found that his second option on the website is honest, and the first one is wrong.
int? Divide(int x, int y)
{
if (y == 0)
return null;
return x / y;
}
Edit: got idea from another article, basically mimicking the F# path, something like this:
Option<int> Divide(int x, int y)
{
if (y == 0)
return Option<int>.CreateEmpty();
return Option<int>.Create(x / y);
}
public class Option<T> : IEnumerable<T>
{
private readonly T[] _data;
private Option(T[] data)
{
_data = data;
}
public static Option<T> Create(T element)
{
return new Option<T>(new T[] { element });
}
public static Option<T> CreateEmpty()
{
return new Option<T>(new T[0]);
}
public IEnumerator<T> GetEnumerator()
{
return ((IEnumerable<T>) _data).GetEnumerator();
}
IEnumerator IEnumerable.GetEnumerator()
{
return GetEnumerator();
}
public void Match(Action<T> onSuccess, Action onError) {
if(_data.Length == 0) {
onError();
} else {
onSuccess(_data[0]);
}
}
}
Ref: https://www.matheus.ro/2017/09/26/design-patterns-and-practices-in-net-option-functional-type-in-csharp/
to call:
public void Main() {
Option<int> result = Divide(1,0);
result.Match(
x => Console.Log(x),
() => Console.Log("divided by zero")
)
}
I just want to mention that NonZeroInteger can definitely be implemented honestly using a variation on Peano numbers:
class NonZeroInteger
{
/// <summary>
/// Creates a non-zero integer with the given value.
/// (This is private, so you don't have to worry about
/// anyone passing in 0.)
/// </summary>
private NonZeroInteger(int value)
{
_value = value;
}
/// <summary>
/// Value of this instance as plain integer.
/// </summary>
public int Value
{
get { return _value; }
}
private readonly int _value;
public static NonZeroInteger PositiveOne = new NonZeroInteger(1);
public static NonZeroInteger NegativeOne = new NonZeroInteger(-1);
/// <summary>
/// Answers a new non-zero integer with a magnitude that is
/// one greater than this instance.
/// </summary>
public NonZeroInteger Increment()
{
var newValue = _value > 0
? _value + 1 // positive number gets more positive
: _value - 1; // negative number gets more negative
return new NonZeroInteger(newValue); // can never be 0
}
}
The only tricky part is that I've defined Increment so that it works with both positive and negative integers. You can create any integer value you want except zero, and no exceptions are ever thrown, so this class is totally honest. (I'm ignoring overflow for now, but I don't think it would be a problem.)
Yes, it requires you to increment by one repeatedly to build large integers, which is extremely inefficient, but that's OK for a toy class like this one. There are probably other honest implementations that would be more efficient (e.g. using a uint as an offset from +1 or -1), but I'll leave that as an exercise for the reader.
You can test it like this:
class Test
{
static int Divide(int x, NonZeroInteger y)
{
return x / y.Value;
}
static void Main()
{
var posThree = NonZeroInteger.PositiveOne
.Increment()
.Increment();
Console.WriteLine(Divide(7, posThree));
var negThree = NonZeroInteger.NegativeOne
.Increment()
.Increment();
Console.WriteLine(Divide(7, negThree));
}
}
Output is:
2
-2
Honestly this is, IMO, overkill, but if I were to do a "Honest" method. I would do something like this. Instead of creating an entire new class. This is not a recommendation of what to do, and could easily cause issues in your code later. The best way to handle this, IMO, is to use the function and catch the exception outside of the Method. This is an "Honest" method in the fact that it always returns an integer, but it could return false values back.
int Divide(int x, int y)
{
try
{
return x / y;
}
catch (DivideByZeroException)
{
return 0;
}
}
This question already has answers here:
When do you use the "this" keyword? [closed]
(31 answers)
Closed 5 years ago.
The older apprentices in my company use "this." a lot.
Two weeks ago I started coding object-oriented and still don't get for what it is being used.
You need to understand what instance is first. Let's say you have an object:
public class House
{
public decimal Height { get; set; }
}
You can have multiple instances of it:
var smallHouse = new House { Height = 100M };
var bigHouse = new House { Height = 300M };
Each instance has its own value of Height. When you want to work with Height in a method of House, you need to refer to the current instance method is operating at (the one consumer called).
This can be done explicitly by using this as a special kind of variable that refers to this current instance:
public class House
{
public decimal Height { get; set; }
public bool IsItTooBig()
{
return this.Height > 200;
}
}
Or you can omit this and let C# guess that what you mean is the instance value:
public class House
{
public decimal Height { get; set; }
public bool IsItTooBig()
{
return Height > 200;
}
}
Programmers differ in opinion whether it's good or bad to be explicit there. If you follow capitalization conventions, you can distinguish instance state and method scope state (normal variables) by it.
There are cases where you absolutely need it, for example when you have naming conflict, or when you want to return current instance from a method:
public class House
{
public decimal Height { get; set; }
public House AddFloor()
{
Height += 100;
return this;
}
}
You should consider applying immutability in many of these cases though.
The keyword 'this' represents the instance of an object used to explicitly call a method, field or property of that instance.
Commonly used when your private fields have the same name as the parameters in a given method:
private string name;
public void SetName(string name) {
this.name = name;
}
When you want to refer to instance field within that class you use this, it can be omitted but there are cases it can not be omitted.
public class InstanceClass
{
int field = 10;
public void Method()
{
int field = 0;
Console.WriteLine(field); // outputs 0
Console.WriteLine(this.field); // outputs 10 because "this" refers to field.
}
}
if there is no declared local variable that conflicts with field name, "this" can be omitted.
public class InstanceClass
{
int _field = 10;
public void Method()
{
int field = 0;
Console.WriteLine(field);
Console.WriteLine(_field); // prefixed with _.
// no conflicts
// so "this" can be omitted.
}
}
another case where you can not omit this, is when you use indexer.
public class InstanceClass
{
private List<int> _source;
private int offset;
public int this[int index] // you use "this"
{
get => _source[index + offset]
set => _source[index + offset] = value;
}
public void Method()
{
var first = this[0]; // must use "this" to refer to indexer for this class.
}
}
"this" is used for calling constructor overloads too.
public class Foo
{
public Foo() : this(0)
{
Console.WriteLine("world");
}
public Foo(int param1)
{
Console.WriteLine("Hello");
}
}
//...
var foo = new Foo(); // outputs "Hello world"
"this" also refers to instance of class itself. so if you want to return instance of self you use this.
public class Foo
{
public Foo ReturnMe() // weird example.
{
return this;
}
}
I am making a game in C#, where you have ammo and a max capacity of it.
Is it possible to make some kind of method like this
ammoInt.Maxed;
so that i can use it like this:
if (ammoInt.Maxed == true) etc.
to check if ammo int is equal to maxAmmoInt?
EDIT:
Thank you for the input, but one last question: do the extension have to be in a seperate class?
You can create an Extension method for int. Like:
public static class MyExtensions
{
public static bool Maxed(this int parameter)
{
return parameter > 100;
}
}
Then you can call it like:
if(ammoInt.Maxed())
Technically, yes. Extension methods provide this in .Net. But this is bad design.
public static class MyExtensions
{
public static public bool IsMaxed( this int value )
{
return value > 50; // or whatever
}
}
int thing = 10;
bool result = thing.IsMaxed( );
This allows you to call that method on any int object. But like I said, you should probably reconsider the design of that, as that is a hack.
The way that I see it is that you have two options.
1) Create a wrapper class that has a bool property that check if its value if greater than 100
public class Ammo
{
public int Value {get; set;}
public bool Maxed
{
get
{
return Value > 100;
}
}
}
2) You can create an Extension Method
public static class CustomExtensions
{
public static bool Maxed(this int value)
{
return value> 100;
}
}
Well I am learning properties and I am not sure about the following:
class X
{
private int y;
public X(int number)
{
this.Y=number; // assign to property
OR
this.y=number //?
}
public int Y;
{
get; set;
}
}
When you use auto-properties (get; set; or a variant thereof), the backing variable is not accessible. Those can, for the most part, be treated as simple variables, especially internally.
If you need to perform custom validation or mutation logic in the mutator, or otherwise have the need for an explicit backing variable, you cannot use auto-properties but have to write stub get and set methods yourself.
They do different things; I would do Y = number; and remove the (unused) field y. In an automatically implemented property, the compiler creates it's own field (with a horrible name that you can't see in C#) - you don't need to provide your own field. So:
class X
{
public X(int y)
{
Y = y;
}
public int Y { get; set; }
}
Other points: changed number to y to be clearer to the caller, and also you don't need this. since it isn't ambiguous (field vs parameter, etc).
Only assign to a field (private int y) inside the property representing that field (public int Y {get;set}). No where else in the class should the backing field be assigned to directly. Always do it through the property... yes even in the constructor. It follows from the do not repeat yourself (DRY) principle.
This is recommended because whenever in future you want to associate some behavior to be triggered by that assignment you only have a single place (the set accessor) to write code into.... not all the places where the field is assigned to !!
class X
{
private int y; //not strictly necessary but good for documentation
public X(int number)
{
Y = number;
}
public int Y { get; set; }
}
When you use autoproperties like:
public int Y;
{
get; set;
}
You don"t need a private property because it's autogenerated. so you class will be:
class X
{
public X(int number)
{
Y = number;
}
public int Y // no semicolon here, comment added for edit length
{
get; set;
}
}
Hope this helps
You have two choices :
class X
{
private int y;
public int Y
{
get { return y; }
set { y = value; }
}
public X(int number)
{
Y = number;
//equivalent to
y = number;
// but you should use the public property setter instead of the private field
}
}
or with auto-properties , it's even simpler :
class X
{
private int y;
public int Y
{
get; set;
}
public X(int number)
{
Y = number;
}
}
When not using auto-properties I always use the Property setter because there can or will be code in the setter that I need to be executed. This code could be a domain check or the raising of an event such as PropertyChanged.
A point I usually try to make about accessing backing variables:
Sometimes the public getter might contain complicated data validation,raising property changed events or some other complex code that is triggered when some external code changes it's value.
When changing that value internally (from inside the class), it might be a valid point to use the backing variable directly if your intention is to skip all the validation and events from the public setter. It's like saying "i'm the class instance, I know what I'm doing". This way the public setter is acting like a guard-dog, sanitizing external input, while I can still set the property internally to whatever I need.
class X
{
private int y; //not strictly necessary but good for documentation
public X(int number)
{
y = GetYValueFromDB(); //we assume the value from DB is already valid
}
public int Y {
get{ return y};
set {
if (ComplexValidation(value)
{
RaiseOnYPropertyChanged();
y = value;
}
}
}
According to MSDN (Section 11.3.6 of the C# spec):
Within an instance constructor of a
struct, this corresponds to an out
parameter of the struct type, and
within an instance function member of
a struct, this corresponds to a ref
parameter of the struct type. In both
cases, this is classified as a
variable, and it is possible to modify
the entire struct for which the
function member was invoked by
assigning to this or by passing this
as a ref or out parameter.
I don't get it. How is this different for a struct than for a class? Code examples are appreciated
Eric Lippert had a fabulous post on mutating readonly structs a while back that will really help clarify the issue for you. There's even a code example, and a quiz!
The salient point is that structs obey value semantics and classes do not and so this must mean something different for the two. this is readonly for a class, but not for a struct. The following code is legal
struct Point {
public int x;
public int y;
public Point(int x, int y) {
this.x = x;
this.y = y;
}
public void DoGoTime() {
GoTime(ref this);
}
public static void GoTime(ref Point p) {
p.x = 100;
p.y = 100;
}
}
but is not if "struct" is replaced by "class."
When you're dealing with structs, you're dealing with value types.
In a class, "this" is a reference to the current instance. This lets you mutate the class instance by setting properties/fields on the class.
However, if you're in a struct, things act differently. When you're in a struct's method, "this" lets you mutate the struct. However, if you're using this in a method, you're almost always dealing with a copy of the "original" struct.
For example:
struct Test
{
int i;
void Mutate() {
this.i += 1;
}
}
When you use this:
void MutateTest(Test instance)
{
instance.Mutate();
}
{
Test test = new Test();
test.i = 3;
Console.WriteLine(test.i); // Writes 3
test.Mutate(); // test.i is now 4
Console.WriteLine(test.i); // Writes 4
MutateTest(test); // MutateTest works on a copy.. "this" is only part of the copy itself
Console.WriteLine(test.i); // Writes 4 still
}
Now, the stranger part - this is valid, and what that quote was saying:
struct Test
{
public Test(int value)
{
this.i = value;
}
int i;
void Mutate(int newValue) {
this = new Test(newValue); // This wouldn't work with classes
}
}
///
{
Test test = new Test();
test.i = 3;
Console.WriteLine(test.i); // Writes 3
test.Mutate(4);
Console.WriteLine(test.i); // Writes 4
Jason's answer and Eric's post show one aspect of this which is interesting... but there's another which is even more alarming:
You can reassign this within a method, even if the type is otherwise immutable.
To demonstrate it, we'll use a struct which is stored in a non-readonly variable, but which contains a readonly field:
using System;
public struct LooksImmutable
{
private readonly int value;
public int Value { get { return value; } }
public LooksImmutable(int value)
{
this.value = value;
}
public void GoCrazy()
{
this = new LooksImmutable(value + 1);
}
}
public class Test
{
static void Main()
{
LooksImmutable x = new LooksImmutable(5);
Console.WriteLine(x.Value);
x.GoCrazy();
Console.WriteLine(x.Value);
}
}