Develop Reference

Is it possible to assign a property of a class assigning it to the instance of that class?

To further explain: i have a class let's say A, with a property of type let's say X; what i would like to do is to be able to instantiate A somewhere and assign the attribute using the instance without accessing the property itself or using methods, and possibly doing some other operation. Something like this:
public class A
{
private X _inside; //it actually can be public also
private DateTime _timeStamp;
public A() {X = new X();}
}
A anInstance = new A();
X aParameter = new X();
anInstance = aParameter
aParameter should be set to the _inside property of anInstance, while also assign DateTime.UtcNow to _timeStamp. Is it possible to do so? I am aware that doing so through a method or get and set is way easier, i'd get the same result and is possibly more efficient, but i would like to do so.
Also, I don't know if this thing has a specific name, therefore this question may be a duplicate; I am highlighting this because i had a problem with circular headers once but i didn't know that they were called so and my question was marked as a duplicate (not an english native seaker), which is not a problem as long as pointing we have an answer.
Anyway, thanks in advance!
Edit lexicon fixed as suggested in the comments

I believe what you're asking for is similar to VB classic's default properties1. Imagine that C# (and .NET in general) had adopted this concept, and that we're allowed to declare one2:
//Not legal c#
public class A
{
public default A _inside {get;set; }
private DateTime _timeStamp;
public A() {}
}
It's perfectly legal for classes to have properties of their own types, and introducing restrictions just for these default properties to avoid the problems I'm about to talk about are worse than disallowing the existence of these default properties3.
So you now have the code:
A anInstance = new A();
A aParameter = new A();
anInstance = aParameter;
Pop quiz - what does line 3 do? Does it assign _inner? Of does it reassign anInstance?
VB classic solved this issue by having two different forms of assignment. Set and Let. And it was a frequent source of bugs (Option Explicit being off by default didn't help here either).
When .NET was being designed, the designers of both C# and VB.Net looked at this and said "nope". You can have indexers (c#)/default properties (VB.Net) but they have to have additional parameters:
public class A
{
private Dictionary<int,A> _inner = new Dictionary<int,A>();
public A this[int i] {
get { return _inner[i]; }
set { _inner[i] = value; }
}
private DateTime _timeStamp;
public A() {}
}
And now we can disambiguate the different assignments in a straightforward manner:
A anInstance = new A();
A aParameter = new A();
anInstance = aParameter;
anInstance[1] = aParameter;
Lines 3 and 4 are, respectively, reassigning the reference and reassigning the property value.
1VB.Net does have default properties but, as discussed later, they're not precisely the same as VB classic's.
2Note that we can't assign it an instance in the constructor now - that would lead to a stack overflow exception since constructing any instance of A would require constructing an additional instance of A which would require constructing an additional instance of A which would...
3A concrete example of this would be a Tree class that has subtrees and a SubTree class that inherits from Tree and has a Parent property of tree. If that were the "default property" for the SubTree class you'd encounter these same property/reference assignment issues discussed lower down if trying to assign a parent of a subtree of a subtree.
Which basically means that you have to disallow default properties of both the actual type in which it's declared and any type to which it's implicitly convertible, which includes all types in its inheritance hierarchy.

Did you think about inheritance?
public class A : X
{
private DateTime _timeStamp;
public A() : base() {}
}
A anInstance = new A();
X aParameter = new X();
anInstance = (A)aParameter;

Why is `this` not available in C# 6.0 Auto-Property Initialization?

I have the following code class:
public class Foo
{
public Nested Bar { get; } = new Nested(this);
public class Nested
{
public Nested(Foo foo)
{
foo.DoSomething();
}
}
private void DoSomething()
{
}
}
However, I get this compile error:
Keyword 'this' is not available in the current context
I can fix it by simply not using Auto-Property Initializer, and explicitly move it into a constructor instead:
public Nested Bar { get; }
public Foo()
{
this.Bar = new Nested(this);
}
Why is it so? Isn't Auto-Property Initializer actually translated into constructor code in IL?

Simply: you can't use this in initializers. The idea is to prevent an incomplete object from escaping - Nested(this) could do anything to your object, leading to very confusing and hard to understand bugs. Keep in mind that initializers execute before any constructor that you add. The same thing fails for field initializers too, in exactly the same way:
private Nested _field = new Nested(this);
Essentially, initializers are intended to perform simple initializations - fixing the 98% problem. Anything involving this is more complex, and you'll need to write your own constructor - and take the blame for any timing issues :)

Why is it so? Isn't Auto-Property Initializer actually translated into constructor code in IL?
The rules for automatically implemented property initializers are the same as those for field initializers, for the same reason. Note that property initializers are executed before base class bodies, just like field initializers - so you're still in the context of a "somewhat uninitialized" object; more so than during a constructor body.
So you should imagine that the property is being converted into this:
private readonly Nested bar = new Nested(this); // Invalid
public Nested Bar
{
get { return bar; }
}
In short, this restriction is to stop you from getting yourself into trouble. If you need to refer to this when initializing a property, just do it manually in a constructor, as per your second example. (It's relatively rare in my experience.)

Strange struct constructor compiler workaround

Structs cannot contain explicit parameterless constructors. Such as:
public struct Person
{
public string Name { get; }
public int Age { get; }
public Person() { Name = string.Empty; Age = 0; }
}
However, this is allowed:
public struct Person
{
public string Name { get; }
public int Age { get; }
public Person(string name = null, int age = 0) { Name = name; Age = age; }
}
Any ideas why? Any reason this is bad to do?

The original answer (see the update below):
The second one is allowed because it is not parameterless. But I wouldn't use optional parameters here because it is very confusing - if you call new Person(), your constructor will not be executed (you can check it if you replace the default values other than null and zero):
public struct Person
{
public string Name { get; }
public int Age { get; }
public Person(string name = "Bob", int age = 42)
{
Name = name;
Age = age;
}
}
So new Person() is the same as default(Person), both will use the initobj MSIL instruction instead of calling a constructor.
So why would it be a problem if you could define a default constructor for structs? Consider the following examples.
private void Test()
{
Person p1 = new Person(); // ok, this is clear, use ctor if possible, otherwise initobj
Person p2 = default(Person); // use initobj
Person p3 = CreateGeneric<Person>(); // and here?
Person[] persons = new Person[100]; // do we have initialized persons?
}
public T CreateGeneric<T>() where T : new()
{
return new T();
}
So real parameterless constructors are not allowed for structs in C# (in CLR it is supported, though). Actually parameterless constructors were planned to be introduced in C# 6.0; however, it caused so many compatibility problems that at the end this feature was removed from the final release.
Update 2022:
Starting with C# 10 parameterless struct constructors are actually supported due to struct records with field initializers. From the docs:
If a record struct does not contain a primary constructor nor any instance constructors, and the record struct has field initializers, the compiler will synthesize a public parameterless instance constructor.
But not as if everything was obvious now. Let's revisit the examples above:
new Person(): Even this case is a bit confusing. Obviously, if you have a parameterless constructor, it will call that one. But unlike in case of classes, if there is no parameterless constructor, it will use the initobj instruction even if there is a constructor overload with optional parameters only (the OP's 2nd example).
default(Person): This is clear, the initobj instruction will be used
CreateGeneric<Person>(): It turns out that it also invokes the parameterless struct constructor... well, at least for the first time. But when targeting .NET Framework, it fails to invoke the constructor for subsequent calls.
new Persons[100]: No constructor call (which is actually expected)
And the feature has some further unexpected implications:
If a field has an initializer and there are only parameterized constructors, then new MyStruct() does not initialize the fields.
Parameter default value initialization like void Method(Person p = new Person()) also fails to call the parameterless constructor. In the meantime this was 'fixed' by emitting CS1736 if there is a parameterless constructor; otherwise, it is allowed and means just default.
If you target .NET Framework, Activator.CreateInstance(Type) also works incorrectly (behaves the same way as CreateGeneric<Person>() above): the constructor is invoked only for the first time.
Expression.New(Type) also works incorrectly, not just in .NET Framework but on all .NET/Core platforms prior version 6.0
And the story is not over. Now it seems that auto-synthesizing parameterless constructor will be removed, which makes the first bullet point above illegal and will be a breaking change from C# 10. But there are also further open issues such as this one, which also needs some changes to language specification.

A parameter-less constructor for a struct will make it more tempting to create mutable structs which are considered evil.
var person = new Person();
person.Age = 35;
...
I am sure there are other reasons, but a major pain is that because they are copied as they are passed around and it is easy to change the wrong struct and therefore easier to make an error that is difficult to diagnose.
public void IncreaseAge(Person p)
{
p += 1; // does not change the original value passed in, only the copy
}

Any ideas why?
This constructor is not implicitly parameterless -- it has 2 parameters.
Any reason this is bad to do?
Here is a reason: The code can be hard to reason about.
You may expect that if you wrote:
var people = new Person[100];
that all People in that array would have the default values for the optional arguments but this is untrue.

The values of optional arguments are hardcoded into the calling code.
If later you choose the change your defaults, all compiled code will retain the values it was compiled with.

The correct way to modify an object that is being passed as a parameter into the modifying class

What is the best way of the following 2 suggestions to modify a property on an object that is being modified by a class that accepts the object as a parameter?
Have the class work on the object and a return a value which you then assign to the object
or.
Pass the object in using the ref keyword and have the class amend the object without actually returning anything.
For example, I have a Person object with a First Name and Last Name and 2 different ways to create the Full Name.
Which is the best way?
public static void Main()
{
Person a = new Person { FirstName = "John", LastName = "Smith" };
Person b = new Person { FirstName = "John", LastName = "Smith" };
NameProcesser np = new NameProcesser();
// Example A
a.FullName = np.CreateFullNameA(a);
// Example B
np.CreateFullNameB(ref b);
}
public class Person
{
public string FirstName { get; set; }
public string LastName { get; set; }
public string FullName { get; set; }
}
public class NameProcesser
{
public string CreateFullNameA(Person person)
{
return person.FirstName + " " + person.LastName;
}
public void CreateFullNameB(ref Person person)
{
person.FullName = person.FirstName + " " + person.LastName;
}
}

You don't need ref. Just modify the object in your method.
When an reference type is passed as a parameter, it is passed "by reference", not by value. So when you modify it, you're actually modifying the original object. You only need ref if you are passing a value type such as an int.
I say "by reference" in quotes, because what is actually happening is that an internal "pointer" to the original object is being passed by value.

First things first
The fact that you're mentioning ref suggests that you are missing a fundamental notion; that is, code that can access a reference to an object can by definition have access to the actual object.
The only conceivable usage scenario in which you would use a ref parameter is when you want to set that reference to some other object, or to null.
If you don't use ref (or even out for that matter, see the difference here) you are actually passing your argument by value, which means that a copy of it is created.
This means two things, depending on whether the parameter is a value type (like int, long, float etc) or a reference type (reference to an instance of whatever class).
If a parameter is a value type, a copy of it will be created. Your method can then do whatever it wants to it, because the copy is only limited to that method's scope.
If a parameter is a reference type, however (as your Person would be), only the reference itself gets copied: the underlying object is the same. This is where the big difference lies. Keep in mind, however, that the reference you have available inside the method is still a copy of the original one, which means that you can set it to null, set it to another object and, in short, do whatever you like with it: once the method has returned, that reference will disappear, and the original one will be left untouched.
That being said
As others told you, there's really no need to use ref.
Moreover, as long as you're dealing with trivial cases such as concatenating first and last name, I would let the object itself do it (exactly like Slapout did).
There's always time to separate responsibilities later should such a need arise.
Consider also that having a separate class for such a trivial task might be also considered counterintuitive.
Say this is the code at hand:
var p = new Person() { FirstName = "John", LastName = "Smith"} ;
Console.WriteLine(p.FullName);
When I do that, I fully expect FullName to return something meaningful (i.e. "John Smith") at all times.
With both your approaches, instead, what will happen if I forget (and I will) to call CreateFullName?
Should you really need to move a given concern into a separate class, hide it inside the property's get method.
That way, people won't need to know about the underpinnings of the classes you wrote, and it's still testable.

Neither - and you don't need 'ref' - just use:
public void CreateFullNameB(Person person)
{
person.FullName = person.FirstName + " " + person.LastName;
}

At first, the only reason to separate the method into a other class is if that method have dependencies like database or network access. Otherwise that simple method should be a property of Person class.
Also it is only reason to pass whole object to method is when object data is widely used inside that method. Otherwise it is better to pass FirstName and LastName as parameters and return result.
Classes don't need to be passed with ref modifier to modify their content. ref is only required if method want assign parameter with a reference to a new instance.
In example you described if choose from two options the return value is better because it makes less coupling and separates logic from data representation. But if few properties of an entity can be updated, then passing object is better.

Can I use Object Initialization Syntax to assign values to properties before the constructor runs?

I am serializing objects to XML using System.Xml.Serialization and this requires me to have parameterless constructors.
I am therefore trying to use Object Initialization Syntax to assign values to certain properties and then use the constructor logic to format these values as needs be before I serialize the objects to XML.
My problem is that the constructor runs before the properties are assigned their values. A simplified example is below:
class Program
{
static void Main(string[] args)
{
Foo myFoo = new Foo() { HelloWorld = "Beer", HelloWorldAgain = "More beer" };
Console.WriteLine(myFoo.HelloWorld);
Console.WriteLine(myFoo.HelloWorldAgain);
Console.ReadLine();
}
}
public class Foo : Bar
{
public string HelloWorld { get; set; }
public Foo()
{
Console.WriteLine("Foo Was Initialized");
Console.WriteLine(HelloWorld);
}
}
public abstract class Bar
{
public string HelloWorldAgain { get; set; }
public Bar()
{
Console.WriteLine("Bar was initialized");
Console.WriteLine(HelloWorldAgain);
}
}
This results in the following output:
As you can see the constructor logic runs, and then the properties are assigned values. I need this to work the other way around.
Is this possible?

Serialization requires you to have a parameterless constructor, but does not limit you to that one constructor.
Keep the no-arg constructor for deserialization, but add another constructor that takes your values and does the required initialization when you need to instantiate the class in code.
Object initialization syntax is just shorthand for setting properties after construction.

No. Object initialization syntax is just a shortcut. When you write:
Foo foo = new Foo { HelloWorld = "Beer" };
The compiler just rewrites this to something very close to what happens if you write:
Foo foo = new Foo();
foo.HelloWorld = "Beer";
If the parameters are required in order for your object to exist, you should put them as arguments in the constructor.

No it's not possible, cause in order to be able to initialize a property of the object, object has already exist. It's existance is guranteed by ctor running before all other stuff.
If we are talking about "not running default constructor", like a conceptual question.
You can do that by using a static property. In that case Foo() will not be called. But it's naturally out of the current question subject.

Arguably, the syntax is deceptive. What is happening here?
var myFoo = new Foo();
myFoo.HelloWorld = "Beer";
myFoo.HelloWorldAgain = "MoreBeer";
That's it, I'm afraid. It's simply not possible to initialise properties before the constructor has run. The constructor is the first thing that 'happens' after memory for the object is allocated and default values are assigned to fields.
BTW, you don't need the parens using the object initialisation syntax. This would be just as good (but even more deceptive):
var myFoo = new Foo { HelloWorld = "Beer", HelloWorldAgain = "MoreBeer" };
Looking at your question, it looks like what you're trying to do (modify the properties before serialisation) doesn't belong in the constructor.