We Keep Coding

Validate object/struct without failing

Assume we have a huge list of numeric cartesian coordinates (5;3)(1;-9) etc. To represent a point in oop I created a struct/object (c#):
public struct Point
{
public int X, Y { get; }
public Point(int x, int y)
{
// Check if x,y falls within certain boundaries (ex. -1000, 1000)
}
}
It might be wrong of how I am using struct. I guess normally you would not use a constructor but this is not the point.
Suppose I want to add a list of 1000 points and there is no guarantee that these coordinates fall within boundaries. Simply if the point is not valid, move to the next one without failing and inform user about it. As for object, I would think that Point should be responsible for instantiation and validation by itself but I am not sure how to deal with it in this particular case. Checking x, y beforehand by the caller would be the simplest approach but it does not feel right because caller would have to handle logic that should reside in Point.
What would the most appropriate approach to validate and handle incorrect coordinates without failing and violating SRP?

You can't do this in the constructor; the constructor either runs succesfully or it doesn't. If it doesn't its because an exception is raised, so, so much for silently failing. You could catch exceptions but that woul basically mean you are using exceptions as a control flow mechanism and that is a big no no, don't do that!
One solution similar to what you are thinking is to use a static factory method:
public struct Point
{
public static bool TryCreatePoint(int x, int y, Bounds bounds, out Point point)
{
if (x and y are inside bounds)
{
point = new Point(x, y);
return true;
}
point = default(Point);
return false;
}
//...
}
And the code adding points to the list should act based upon creation success.
Fun fact: if you are using C# 7 the code could look a lot cleaner:
public static (bool Succesful, Point NewPoint) TryCreatePoint(int x, int y, Bounds bounds)
{
if (x and y are inside bounds)
return (true, new Point(x, y));
return (false, default(Point));
}

I can think of three options:
Have the constructor throw an exception that you catch. This is not really great if you are expecting a lot of failures.
Have an IsValid property on the struct that you can use to filter it out once created.
Have the thing loading the data take responsibility for validating the data as well. This would be my preferred option. You say "it does not feel right because caller would have to handle logic that should reside in Point" but I would argue that the responsibility for checking that loaded data is correct is with the thing loading the data, not the data type. You could also have it throw an ArgumentOutOfRangeException in the constructor if the inputs are not valid now that you are no longer expecting anything invalid to be passed as a belt and bracers approach to things.

What you want to do is simply not posible, an instance of a class is either fully created or not at all. If the constructor has been called the only way to not instantiate an instance is by throwing an exception.
So you have these two opportunities to do this:
Extract a method Validate that returns a bool and can be called from the caller of your class.
public struct Point
{
public int X, Y { get; }
public Point(int x, int y)
{
}
}
public bool Validate() { return -1000 <= X && X <= 1000 && -1000 <= Y and Y <= 1000; }
Of course you could do the same using a property.
Throw an exception in the constructor
public Point(int x, int y)
{
if(x > 1000) throw new ArgumentException("Value must be smaller 1000");
// ...
}
However the best solution IMHO is to validate the input before you even think about creating a point, that is check the arguments passed to the constructor beforehand:
if(...)
p = new Point(x, y);
else
...

To be honest, Point shouldn't check boundaries, so the caller should do that. A point is valid in the range that their X and Y can operate (int.MinValue and int.MaxValue). So a -1000000,2000000 is a valid point. The problem is that this point isn't valid for YOUR application, so YOUR application (the caller), the one who is using point, should have that logic, not inside the point constructor.

Structs in C# are funny so I'll add another "funny" way to check:
struct Point
{
int _x;
public int X
{
get { return _x; }
set { _x = value; ForceValidate(); }
} // simple getter & setter for X
int _y;
public int Y
{
get { return _y; }
set { _y = value; ForceValidate(); }
} // simple getter & setter for Y
void ForceValidate()
{
const MAX = 1000;
const MIN = -1000;
if(this.X >= MIN && this.X <= MAX && this.Y >= MIN && this.Y <= MAX)
{
return;
}
this = default(Point); // Yes you can reasign "this" in structs using C#
}
}

Anonymous object ~ object does not contain a definition for property

The following code will not compile if I include f1().
However, I see both X & Y in intellisense with their values at the call to calculationXY() in the call from f2().
The f1() compile error is: object does not contain a definition or x {or for y for that matter and the .x is red underlined.
private object calculateXY(int id) {
// bla bla bla
return (new { x = calX, y = calY });
}
/*
f1() {
var p = calculateXY(10);
p.x + 1;
}
*/
f2() {
var p = calculateXY(10);
//p.x + 1;
}

I'm added this just to complete the answer.
In the whole solution this class is only instantiated twice. And it is small so I think I'm okay.
public class plotPoint {
public plotPoint (int x, int y){
this.x = x;
this.y = y;
}
public int x { get; set; }
public int y { get; set; }
}
and
private plotPoint calculateXY(int id) {
//bla bla bla
return (new plotPoint(_pointX, _pointY));
}
Although I don't exactly love the name.
I guess I've been doing to much javascript lately. JS would have a problem with what I was hoping to get away with. Oh well.
And so we see the death of yet another pointlessly crazy use of a global variable.
Thanks for everyone's input.

calculateXY returns an object .. which has no x or y properties; you
can return a dynamic instead, or use reflection to read x and y –
KMoussa
and
As #KMoussa states, you're returning an object. Best bet is to return
dynamic, but if you're returning an object, you should just return a
proper class or struct. – TyCobb
Thanks guys.

I'd recommend writing an IntPoint class:
public class IntPoint { int X; int Y; }
And return that. Make sure you declare the method's return type as IntPoint as well, so you can easily use the return value without any nonsense:
private IntPoint CalculateXY(int id) {
// bla bla bla
return new IntPoint { X = calX, Y = calY };
}
...
IntPoint ip = CalculateXY(12);
Console.WriteLine(ip.X);
I would not advise using dynamic for this. If you do it the way I suggest above, that puts the compiler in your corner, working on your behalf to make sure that any code that calls your method knows what it's getting and uses it properly. dynamic is meant for other things, usually fairly exotic things -- I've known about it for years and never yet used it in production code.
Anonymous types, like in your original example, are virtually never returned from methods. That's exotic stuff too, for reasons you discovered already. It's a little more hassle to find a suitable return type sometimes (or write one, as we did above), but it's generally worth the effort.
UPDATE
Here's another option:
private void CalculateXY(int id, out int x, out int y) {
// bla bla bla
x = calX;
y = calY;
}
Call like...
int x, y;
CalculateXY(32, out int x, out int y);
It's not my absolute favorite, but it's an option that's strongly typed, properly named, and doesn't require writing a new class just to hold a return type. I wouldn't mind seeing that in code.
In comments, #KMoussa suggested Tuple<int,int> for a return type. That's feasible, and if it's a private helper function it's not the worst thing you can do, but if the code is being maintained the "Item2 who?" cost over time will exceed the up-front cost of writing a quickie class. Tuple was, IIRC, originally designed to do what anonymous types are now used for.

Is the order of member initializers in an object initializer deterministic? [duplicate]

Does the order in which I set properties using the object initializer syntax get executed in the exact same order?
For instance if I do this:
var s = new Person { FirstName = "Micah",
LastName = "Martin",
IsLoaded = true
}
will each property get set in the same order?

Yes.
Apologies for getting interrupted (I have to actually do some work every so often). The spec doesn't explicitly say it, but it makes it pretty clear IMO in section 7.6.10.2:
An object initializer consists of a sequence of member initializers, enclosed by { and } tokens and separated by commas.
(Note the word "sequence" here, rather than "set". I personally think that's significant, as a sequence is ordered.)
The following class represents a point with two coordinates:
public class Point
{
int x, y;
public int X { get { return x; } set { x = value; } }
public int Y { get { return y; } set { y = value; } }
}
An instance of Point can be created and initialized as follows:
Point a = new Point { X = 0, Y = 1 };
which has the same effect as
Point __a = new Point();
__a.X = 0;
__a.Y = 1;
Point a = __a;
where __a is an otherwise invisible and inaccessible temporary variable.
EDIT: I've had a response from Mads Torgersen, who has basically said that anything which can be done now will preserve the order. There may be some oddities in future where the order is not preserved in weird cases where you're doing something other than setting a property/field, but that will depend on where the language goes.
It's worth pointing out that there are actually lots of steps going on here - there's the order of execution of the evaluation of the arguments (i.e. the RHS bits) and the order of execution of the assignments. For example, if you have:
new Foo
{
A = X,
B = Y
}
all the following orders are possible while still maintaining the order of the actual property execution (A and B):
Evaluate X, assign to A, evaluate Y, assign to B
Evaluate X, evaluate Y, assign to A, assign to B
Evaluate Y, evaluate X, assign to A, assign to B
I believe the first option is the one actually taken, but this was just to demonstrate that there's more to it than meets the eye.
I would also be very wary of actually writing code which depends on this...

Accessing and changing structs as property vs as field

Ok, I'll start my question saying that I understand the evil behind mutable structs, but I'm working with SFML.net and using a lot of Vector2f and such structs.
What I don't get it is why I can have, and change the values of, a field in a class and can't do the same with a property, in the very same class.
Take a look at this code:
using System;
namespace Test
{
public struct TestStruct
{
public string Value;
}
class Program
{
TestStruct structA;
TestStruct structB { get; set; }
static void Main(string[] args)
{
Program program = new Program();
// This Works
program.structA.Value = "Test A";
// This fails with the following error:
// Cannot modify the return value of 'Test.Program.structB'
// because it is not a variable
//program.structB.Value = "Test B";
TestStruct copy = program.structB;
copy.Value = "Test B";
Console.WriteLine(program.structA.Value); // "Test A"
Console.WriteLine(program.structB.Value); // Empty, as expected
}
}
}
note: I'll build my own classes to cover the same functionality and keep with my mutability, but I can't see a technical reason why I can do one and can't do other.

When you access a field, you are accessing the actual struct. When you access it through property, you call a method that returns whatever is stored in the property. In the case of a struct, which is a value type, you will get back a copy of the struct. Apparently that copy is not a variable and cannot be changed.
Section "1.7 Structs" of the C# language specification 5.0 says:
With classes, it is possible for two variables to reference the same
object and thus possible for operations on one variable to affect the
object referenced by the other variable. With structs, the variables
each have their own copy of the data, and it is not possible for
operations on one to affect the other.
That explains that you will receive a copy of the struct and not be able to modify the original struct. However, it doesn't describe why it isn't allowed.
Section "11.3.3" of the specifcation:
When a property or indexer of a struct is the target of an assignment,
the instance expression associated with the property or indexer access
must be classified as a variable. If the instance expression is
classified as a value, a compile-time error occurs. This is described
in further detail in §7.17.1.
So the returned "thing" from the get accessor is a value and not a variable. That explains the wording in the error message.
The specification also contains an example in section 7.17.1 that is nearly identical to your code:
Given the declarations:
struct Point
{
int x, y;
public Point(int x, int y) {
this.x = x;
this.y = y;
}
public int X {
get { return x; }
set { x = value; }
}
public int Y {
get { return y; }
set { y = value; }
}
}
struct Rectangle
{
Point a, b;
public Rectangle(Point a, Point b) {
this.a = a;
this.b = b;
}
public Point A {
get { return a; }
set { a = value; }
}
public Point B {
get { return b; }
set { b = value; }
}
}
in the example
Point p = new Point();
p.X = 100;
p.Y = 100;
Rectangle r = new Rectangle();
r.A = new Point(10, 10);
r.B = p;
the assignments to p.X, p.Y, r.A, and r.B are permitted because p and r are variables. However, in the example
Rectangle r = new Rectangle();
r.A.X = 10;
r.A.Y = 10;
r.B.X = 100;
r.B.Y = 100;
the assignments are all invalid, since r.A and r.B are not variables.

Although properties look like variables, each property is really a combination of a get method and/or a set method. Typically a property get method will return a copy of what's in some variable or array slot, and a put method will copy its parameter into that variable or array slot. If one wants to do something like someVariable = someObject.someProeprty; or someobject.someProperty = someVariable;, it won't matter that those statements end up being executed as var temp=someObject.somePropertyBackingField; someVariable=temp; and var temp=someVariable; someObject.somePropertyBackingField=temp;, respectively. On the other hand, there are some operations which can be done with fields but cannot be done with properties.
If an object George exposes a field named Field1, then code may pass George.Field as a ref or out parameter to another method. Additionally, if the type of Field1 is a value type with exposed fields, then an attempt to access those fields will access the fields of the struct that is stored within George. If Field1 has exposed properties or methods, then accessing those will cause George.Field1 to be passed to those methods as though it were a ref parameter.
If George exposes a property named Property1, then an access of Property1 which is not the left side of an assignment operator will call the "get" method and store its result in a temporary variable. An attempt to read a field of Property1 will read that field from the temporary variable. An attempt to call a property getter or method on Property1 will pass that temporary variable as a ref parameter to that method and then discard it after the method returns. Within the method or property getter or method, this will refer to the temporary variable, and any changes the method makes to this will be discarded.
Because it would make no sense to write to fields of a temporary variable, attempts to write to fields of a property are forbidden. Additionally, present versions of the C# compiler will guess that property setters would be likely to modify this and will thus forbid any use of property setters even when they would in fact not modify the underlying structure [e.g. the reason ArraySegment includes an indexed get method and not an indexed set method is that if one were to try to say e.g. thing.theArraySegment[3] = 4; the compiler would think one was trying to trying to modify the structure returned by the theArraySegment property, rather than modify the array whose reference is encapsulated therein]. It would be extremely useful if one could specify that particular structure methods will modify this and should not be invokable on structure properties, but as yet no mechanism exists for that.
If one wants to write to a field contained within a property, the best pattern is usually:
var temp = myThing.myProperty; // Assume `temp` is a coordinate-point structure
temp.X += 5;
myThing.myProperty = temp;
If the type of myProperty is designed to encapsulate a fixed set of related but independent values (such as the coordinates of a point), it's best if it exposes those variables as fields. Although some people seem to prefer to design structs so as to require constructs like:
var temp = myThing.myProperty; // Assume `temp` is some kind of XNA Point structure
myThing.myProperty = new CoordinatePoint(temp.X+5, temp.Y);
I would regard such code as less readable, less efficient, and more error-prone than the previous style. Among other things, if CoordinatePoint happens to e.g. expose a constructor with parameters X,Y,Z as well as a constructor which takes parameters X,Y and assumes Z is zero, code like the second form would zero out Z without any indication that it was doing so (intentionally or unintentionally). By contrast, if X is an exposed field, it's much clearer that the first form would only modify X.
In some cases, it may be helpful for a class to expose an internal field or array slot via a method that passes it as a ref parameter to a user-defined routine, e.g. a List<T>-like class might expose:
delegate void ActByRef<T1>(ref T1 p1);
delegate void ActByRef<T1,T2>(ref T1 p1, ref T2 p2);
void ActOnItem(int index, ActByRef<T> proc)
{
proc(ref BackingArray[index]);
}
void ActOnItem<PT>(int index, ActByRef<T,PT> proc, ref PT extraParam)
{
proc(ref BackingArray[index], ref extraParam);
}
Code which had a FancyList<CoordinatePoint> and wanted to add some local variable dx to field X of item 5 in iit could then do:
myList.ActOnItem(5, (ref Point pt, ref int ddx) => pt.X += ddx, ref dx);
Note that this approach would allow in-place modification of data in the list, and even allow the use of such methods as Interlocked.CompareExchange). Unfortunately, there's no possible mechanism by which a type which derives from List<T> can support such a method, and no mechanism by which a type which does support such a method can be passed to code which expects a List<T>.

Multidimensional List C#

I need to create a multidimensional guard List three values​​, X, Y and Z, and I need a List that is because once the value is queried, the array must be removed.
The query would look something like this: List [0] [0] = X, List [0] [a] = Y and List [0] [2] = X, so that I can remove only the index 0 and he already remove all the other three.

If you need to create a multidimensional list, you can always create a list of lists like so:
var multiDimensionalList = new List<List<string>>{
new List<string>{"A","B","C"},
new List<string>{"D","E","F"},
new List<string>{"G","H","I"},
};
Console.WriteLine(multiDimensionalList[2][1]); // Prints H
multiDimensionalList[2].RemoveAt(1);
Console.WriteLine(multiDimensionalList[2][1]); // Prints I
multiDimensionalList[2][1] = "Q";
Console.WriteLine(multiDimensionalList[2][1]); // Prints Q
Be aware though that attempting to replace a value that doesn't exist by way of assignment will throw an exception:
multiDimensionalList[2][5] = "R"; // Throws an ArgumentOutOfRangeException

Your question is very hard to understand, but perhaps what you are looking for can be accomplished with an array of arrays? This is how multidimensional arrays are implemented in some languages anyways.
In your case you might be using a List of List's: List>. And this would satisfy your requirement to remove "all the other three" by removing the first element in the outer List<> object.

I'm sorry but your question is a little bit hard to understand, but I will take a stab at it. Please don't interchange the words Array and List as they are different yet related ideas in C#. I believe that you mean Array with your use of [] brackets. Although you might want to consider using lists as they have a nice way to remove certain elements from a list by using the element. the MSDN has some good information as to how you might proceed.
List(T).Remove method
the list will restructure it self to remove or add elements as desired.

I am not sure I am following your logic as you are using both strings and integers as your second indexer, and referencing X twice, but not Z. Assuming these are typos, I am going to take a guess at what you want.
Have you considered a custom type with X, Y, AND Z properties, and an indexer to give you the behavior you described:
You also don't mention what types your values are, so I am using object, but feel free to substitute your own type (or a generic type)
public class MyType
{
private object[] backingArray = new object[3];
public object this[int index]
{
get { return backingArray[index]; }
set { backingArray[index] = value; }
}
public object X
{
get { return backingArray[0]; }
set { backingArray[0] = value; }
}
public object Y
{
get { return backingArray[1]; }
set { backingArray[1] = value; }
}
public object Z
{
get { return backingArray[2]; }
set { backingArray[2] = value; }
}
}
You could then use it like this:
List<MyType> list = new List<MyType>();
list = PopulateList(); // fill list with values
var x = list[0][0];
var y = list[0][1];
var z = list[0][2];
Of course, this implementation depends on your 2nd dimension always consisting of 3 elements. If it will not be consistent, then one of the other answers abound for your needs.