I know that when using auto-properties, the compiler creates its own backing field behind the screen. However, in many programs I read to learn from, I see people explicitly write
private int _backingField;
public int Property { get { return _backingField; } }
What is the difference between above, and below?
public int Property { get; private set; }
I understand that its obvious to use the property when you actually have side-effects in the getter or setter, but that's often not the case. Also, I understand that you have to explicitly use the backing field in the case of structs, you can't access their members via properties.
The only difference I have been able to find is that the way of calling the value is different inside the class it is defined in. Is it then simple preference, or is there something more to calling a value through its property or by directly accessing the field?
Simple conventions?
There's not much difference between those two snippets - you can't pass a property by reference, for example, but that's rarely an issue. However, if you want the field to be readonly, like this:
private readonly int _backingField;
public int Property { get { return _backingField; } }
then there's a difference. The code I've written above prevents the value from being changed elsewhere within the class, making it clear that this is really meant to be immutable. I'd really like to be able to declare a read-only field with a read-only automatically implement property, settable only within the constructor - but that's not available at the moment.
This is rather confusing, by the way:
Also, I understand that you have to explicitly use the backing field in the case of structs, you can't access their members via properties.
What do you mean? You can definitely use properties within structs. Are you talking about backing fields which are mutable structs, i.e. the difference between:
foo.someField.X = 10;
and
foo.SomeProperty.X = 10;
? If so, I normally avoid that being an issue by making my structs immutable to start with :)
Related
Please explain the following error on struct constructor. If i change struct to class
the erros are gone.
public struct DealImportRequest
{
public DealRequestBase DealReq { get; set; }
public int ImportRetryCounter { get; set; }
public DealImportRequest(DealRequestBase drb)
{
DealReq = drb;
ImportRetryCounter = 0;
}
}
error CS0188: The 'this' object cannot be used before all of its fields are assigned to
error CS0843: Backing field for automatically implemented property
'DealImportRequest.DealReq' must be fully assigned before control is returned to the caller. Consider calling the default constructor from a constructor initializer.
As the error message recommends, you can resolve this by calling the default constructor from a constructor initializer.
public DealImportRequest(DealRequestBase drb) : this()
{
DealReq = drb;
ImportRetryCounter = 0;
}
From the language specification:
10.7.3 Automatically implemented properties
When a property is
specified as an automatically
implemented property, a hidden backing
field is automatically available for
the property, and the accessors are
implemented to read from and write to
that backing field. [...] Because the
backing field is inaccessible, it can
be read and written only through the
property accessors, even within the
containing type. [...] This
restriction also means that definite
assignment of struct types with
auto-implemented properties can only
be achieved using the standard
constructor of the struct, since
assigning to the property itself
requires the struct to be definitely
assigned. This means that user-defined
constructors must call the default
constructor.
The other (more verbose) alternative, of course, is to manually implement the properties and set the backing fields yourself in the constructor.
Do note that the struct you have there is mutable. This is not recommended. I suggest you either make the type a class (your compilation problems should go away immediately) or make the type immutable. The easiest way to accomplish this, assuming the code you have presented is the entire struct, would be to make the setters private (get; private set;). Of course, you should also make sure that you don't add any mutating methods to the struct afterwards that rely on private access to modify the fields. Alternatively, you could back the properties with readonly backing fields and get rid of the setters altogether.
The code you have is equivalent to the following code:
public struct DealImportRequest
{
private DealRequestBase _dr;
private int _irc;
public DealRequestBase DealReq
{
get { return _dr; }
set { _dr = value; }
}
public int ImportRetryCounter
{
get { return _irc; }
set { _irc = value; }
}
/* Note we aren't allowed to do this explicitly - this is didactic code only and isn't allowed for real*/
public DealImportRequest()
{
this._dr = default(DealRequestBase); // i.e. null or default depending on whether this is reference or value type.
this._irc = default(int); // i.e. 0
}
public DealImportRequest(DealRequestBase drb)
{
this.DealReq = drb;
this.ImportRetryCounter = 0;
}
}
Now, all I have done here is remove the syntactic sugar that:
Implements automatic properties.
Works out which members are dealt with relative to this.
Gives all structs a default no-parameter constructor.
The first two are optional (you could write them explicitly if you wished) but the third is not - we aren't allowed to write our own code for a struct's parameterless constructor, we have to go with one that works like the one in the code above being given to us automatically.
Now, looked at here, suddenly the meaning of the two errors becomes clear - your constructor is implicitly using this before it's fields are assigned (error 188) and those fields are those backing the automatic properties (error 843).
It's a combination of different automatic features that normally we don't have to think about, but in this case don't work well. We can fix this by following the advice in the error message for 843 and calling the default constructor as part of your explicit constructor:
public DealImportRequest(DealRequestBase drb)
:this()
{
DealReq = drb;
ImportRetryCounter = 0;
}
Considering this in relation to my expanded version of your code above, you can see how this solves the problem, because it calls the constructor that assigns to the backing fields before it proceeds.
I would recommend not using auto-properties with structures unless you have a good reason to use them. Wrapping a class field in a read-write property is useful because it makes it possible for an instance to control the circumstances where it may be read or written, and take action when a read or write takes place. Further, code within an object instance can identify the instance being acted upon, and may thus perform a special action only when reading and writing a particular instance. Using an auto-property in an early version of a class will make it possible for future versions of the class to use a manually-implemented property including the aforementioned benefits while retaining compatibility with already-compiled client code. Unfortunately, wrapping a struct field in a read-write property doesn't offer those same benefits because the fields of one struct instance can be copied to another without either instance having any say in the matter. If the semantics of a struct allow a property to be written with arbitrary values in most instances [as would be the case for an auto-property], then any legitimate replacement would be semantically equivalent to a field.
I know that automatic properties must define a get and set accessor method, I also know that it is possible for either of these accessors to be made invisible by means of an access modifier.
Is there a technical reason why the compiler is happy with
public object Property { get; set; }
but not
public object Property { get; }
My (possibly wrong) understanding of this code is that the compiler generates a backing field that is hidden from the calling code like so:
private object hiddenField; //hidden by compiler.
public object Property
{
get { return hiddenField; }
set { hiddenField = value;}
}
If the compiler can generate that, is there a reason that it can't omit the set accessor function based on the presence (or lack thereof) of a setter in the property declaration.
I understand that this may be an issue of feature scope rather than a technical limitation, I also freely admit that I have not yet consulted the C# language specification as yet.
[UPDATE 2]
Forgive me...I'm an idiot :P, I see now, thank you everyone for tollerating my senior moment/
Without the set accessor, there is no way to set the value, since you don't have a way to access "hiddenField".
Similarly, without a get accessor, there would be no way to get back a value you set.
Since it really becomes useless, it's not allowed.
However, you can have different accessibility on the two methods:
public object Property { get; private set; }
This provides you the ability to hide the set from outside, but still have a usable property.
public object Property { get; private set; }
will work, and it will have the semantics you expect it to.
How could you use a property such the following?
public object Property { get; }
Theoritically if you could write something like that it always returns null as it lacks to the set accessor. I think it is useless unless you set the hidden field in some way to have a static value to always return it.
From the C# spec:
Because the backing field is
inaccessible, it can be read and
written only through the property
accessors, even within the containing
type.
Leaving one of the accessors out would mean that the property would either be read-only or write-only, even within the constructor of the class/struct. Not very useful.
I know how to use properties and I understand that they implicitly call underlying get and set accessors, depending on whether we are writing to or reading from a property.
static void Main(string[] args)
{
A a = new A();
(a.b).i = 100;
}
class A
{
private B _b = new B();
public B b
{
get { return _b; }
}
}
class B
{
public int i;
}
What code (a.b).i = 100; essentially does is that first property’s get accessor returns a reference to an object _b, and once we have this reference, we are able to access _b’s members and change their values.
Thus, in our example, having read only property only prevents outside code from changing the value of a reference variable _b, but it doesn’t prevent outside code from accessing _b’s members.
So it seems that property can only detect whether we are trying to read from or write to a variable ( in our case variable _b ) located on the stack, while it’s not able to detect whether we’re trying to also write to members of an object to which the variable on the stack ( assuming this variable is of reference type ) points to.
a) But doesn’t that defeat the whole purpose of having read-only properties? Wouldn’t it be more effective if properties had the ability to also detect whether we’re trying to access members of an object returned by get accessor( assuming backing field is of a reference type )?
thank you
Immutability is not transitive; you can't expect mutable objects into an immutable accessor to be immutable.
Your reference is read only, not your object.
Imagine a class like this:
public class A
{
private List<int> _myList<int> = new List<int>();
public List<int> MyList { get { return _myList; } }
}
Now, users of the class can add and remove and access items in the list, but they cannot replace the list itself. This is important. It allows you to do things inside the class like assume the _myList member is never null, for example.
Put a more general way, this paradigm allows you do define an interface into your class such that users can use the types in the properties you expose, but they cannot just swap instances of complex types out from under you.
No, it does not defeat the purpose of read-only properties.
It is possible to use read-only properties that don't let the user change the underlying data. For example, you can have your property return a System.Collections.ObjectModel.ReadOnlyCollection even though the underlying type is a List. This, of course, won't prevent the user from changing the properties of the items in the collection.
Of course you can access B.i; it's public. You're thinking that since _b is private, all methods should be private when fetched through A? In that case it's pretty useless as you wouldn't be able to use B for anything.
You ask:
Doesn’t that defeat the whole purpose
of having read-only properties?
But look: your B.i member is a public field.
I ask you, then: what is the purpose of having a public field? It only makes sense if you want users of your code to be able to change that field's value. If you don't want that, it should be a private field, or (if you want to provide read but not write access) a property with a private set accessor.
So there's your answer. private B _b serves its purpose in the code you posted quite well (_b cannot be externally set to something new), just as public int i serves its purpose equally well (i can be externally changed).
Reference immutability is a popular feature request. Too bad its is so dramatically non CLS compliant. Very few languages have this notion, I only know of C++ (but don't get out much).
The key problem that this needs to be enforced by the CLR. C++ doesn't need to enforce this at runtime, only a C++ compiler is required to ensure that const contracts are observed. It has no support at all for language interop, beyond a bolt-on like COM.
This won't fly in .NET, there's little point in declaring a reference immutable and have that verified by the compiler when another language can stomp all over it because it doesn't have the syntax to express immutability. I reckon we'll get it some day, not Real Soon.
As a minor point, you don't have to write (a.b).i = 100; but simply
a.b.i = 100;
Back to your question, I don't think it defeats the purpose. You can still not do the following:
a.b = new B();
because there's no public set(). If you want the member i of class B to be read only, you can do the same thing as you did to member _b of class A by making it private and providing a public get(), but not set(). Off the top my head, doing what you propose might lead to many unexpected consistencies (I'm sure the language designers did not overlook this).
Entirely dependent on the situation, but read only access to a mutable object is a commonly used design. In many cases you simply want to ensure that the object itself remains the same.
Some classes (like String object in Java, and I believe in C# as well) are entirely immutable, where as others are only partially mutable. Consider an ActiveRecord style of object for which most fields are mutable, but the ID is immutable. If your class holds an ActiveRecord in a read only property, external classes cannot swap it for a different ActiveRecord object and thus change the ID, which might break assumptions within your class.
I disagree. Your property is for the class B, not for the members of class B. This means you can't assign a new Object to b. It doesn't mean that B's public members suddenly become private.
readonly applies to the class property, not the object that the property refers to. It keeps you from being able to write a.b = new B();, and that is all it does. It places no constraints on what you can do to the object once you get a reference to it. I think what you are discovering is that readonly make the most sense when applied to value types or immutable class types.
Another use case:
interface INamedPerson
{
String Name { get; }
}
class Bob : INamedPerson
{
public String Name { get; set; }
}
class Office
{
// initialisation code....
public INamedPerson TheBoss { get; }
public IEnumerable<INamedPerson> Minions { get; }
}
Now, if you have an instance of the Office, as long as you don't go cheating with casts, you have read-only access to everyone's names, but can't change any of them.
Ah. Encapsulation does the instantiated class inherit the containing class's access level. Exposing type B as a public property of type A. 'B.i' is public so it should be accessible from outside the same way 'A.b' is public.
A.b returns a reference of a privately accessible type B, however type B has a publicly accessible field i. My understanding is that you can set the i field of B but you can't set the b property of A externally. The B type property of A is readonly however the reference to type B does not define the same readonly access to its fields.
I'm sure you can modify the definition of type B to suit your need for the access level of B's fields or properties.
could someone explain me what's the idea behind using Auto-Implemented Properties c#?
public class Customer
{
public int ID { get; set; }
public string Name { get; set; }
}
I get the motivation to use properties for private field, so we can determine how one can access a private field. But here - it's just like defining the field to be public from the first place. no?
Is there a difference between defining a field to be "public const" or define it to have a get-only property ?
A public automatic property is not the same as a public field, they are not binary compatible. If you implement a public field and later on want to add some logic, you will have to change it into a property and thereby introduce a breaking change (because of the binary incompatibility). This is the reason why many conventions state that you should never expose public fields but rather use properties.
So, automatic properties are just a convenient starting point for any simple non-private class value member, allowing one to add logic later on while keeping binary compatibility.
Properties can be databound, whereas fields can not.
Automatically implemented properties are essentially syntactic sugar. Once compiled, the backing store exists. It just isn't available from the source code.
As others have stated, properties and fields are not equivalent. Fields and properties aren't compatible so changing between them is a breaking change. In addition, you cannot use data binding with fields.
Final point. Though in your case there's little functional difference between the example and a public field, you can change the visibility of one of the accessors. So, to create a read-only property using an automatic property, you may do something like:
public int ID { get; private set; }
In this case, the get accessor is public, as per the entire signature, but the set accessor is private.
I will let MSDN do the talking here....
"In C# 3.0 and later, auto-implemented properties make property-declaration more concise when no additional logic is required in the property accessors. They also enable client code to create objects. When you declare a property as shown in the following example (see MSDN article for example), the compiler creates a private, anonymous backing field that can only be accessed through the property's get and set accessors"
Probably the most advantageous difference is you can do pre/post validation, raise PropertyChanged events etc
Is there a difference between defining a field to be "public const" or define it to have a get-only property?
Yes, a get-only field must have a private field declaration. This field can be changed by the class internally, marking a field as const means it cannot be modified.
2: a public const has to be defined at compiletime, you cannot use reference objects for that. Only classes that inherit from System.ValueType (string, int, double, ...)
A const is also static whereas a property with only a getter is not (every class has it's own instance.)
Add logic to getter function. Can access values of another property
public string Status
{
get { return DeactivateDate != null ? "InActive" : "Active"; }
private set { }
}
This question came up in the comments of this answer. The inability to have readonly properties was proposed as a potential reason to use fields instead of properties.
For example:
class Rectangle
{
private readonly int _width;
private readonly int _height;
public Rectangle(int width, int height)
{
_width = width;
_height = height;
}
public int Width { get { return _width; } }
public int Height { get { return _height; } }
}
But why can't you just do this?
public int Width { get; readonly set; }
Edit (clarification): You can achieve this functionality in the first example. But why can't you use the auto-implemented property shorthand to do the same thing? It would also be less messy, since you wouldn't have to directly access the fields in your constructor; all access would be through the property.
Edit (update): As of C# 6.0, readonly properties are supported! object MyProp { get; } This property can be set inline (object MyProp { get; } = ...) or in the constructor, but nowhere else (just like readonly fields).
Because the language doesn't allow it.
This may seem like a frivolous answer: after all, the language designers could have declared that if you used readonly on an automatic property then it would mean "the property is settable but only in the constructor".
But features don't come for free. (Eric Gunnerson expresses it as "Every feature starts with minus 100 points.") To implement read-only automatic properties would have required additional compiler effort to support the readonly modifier on a property (it currently applies only to fields), to generate the appropriate backing field and to transform sets of the property to assignments to the backing field. That's quite a bit of work to support something that the user could do reasonably easily by declaring a readonly backing field and writing a one-line property getter, and that work would have a cost in terms of not implementing other features.
So, quite seriously, the answer is that either the language designers and implementers either never thought of the idea, or -- more likely -- they thought it would be nice to have, but decided there were better places to spend their finite resources. There's no technical constraint that prevents the language designers and implementers providing the feature you suggest: the reasons are more about the economics of software development.
If you want to make a property "read only" as far as functionality is concerned, you do so by only supplying the get method, as you indicated in your post.
public int Width { get { return _width; } }
public int Height { get { return _height; } }
The compiler will even reference these as "read only" if you try to write to them.
Having an additional term of readonly for a property would clash with also providing the set method. It seems to be poor syntax to me, i.e. how does the person reading it (or the compiler, for that matter) know what takes precedence: readonly or set?
Furthermore, as was explained in the answer you referenced, readonly applies only to fields and limits writing to those fields to the instantiation of the class. With properties, you can't write to them (I don't think) even within the constructor if they only have a get method.
You can make an automatic property read only by specifying the private access modifier for set like so
public bool Property {get; private set;}
The setter is still defined but it is no longer visible outside the class where the property is defined. As an aside, it is sometimes useful to define the setter as internal so that properties can be easily set from within the same assembly, but not by external callers.
Properties can be read-only, just not automatic properties.
Both get and set are required for automatic properties, and it makes no sense for a read-only property to have a set.
You can define a regular property as a read-only property by just defining the get - however, even if the requirement for both get and set for automatic properties didn't exist - the read-only property couldn't be automatically defined because you have to know the backing field to be able to set it's value internally (i.e. through the constructor).
I suppose there could be a template/macro or something defined in VS to generate the code this, but it couldn't be a part of the language itself.
I think fundamentally the problem is that properties are merely syntactic sugar for a field with optional getter/setter methods. Automatic properties generate the backing field so they require the "setter" or there would be no way to set the value of the backing field. Since properties really map onto methods, not fields, it doesn't make any sense to make them readonly.
Even if allowed, readonly could only apply to automatic properties. For traditional properties, you can put arbitrary code in both the getter and the setter. Even if the setter were able to be invoked only in the constructor of the class, the getter could still mutate the value based on whatever logic you decided to put in it. This would wholly inconsistent with the concept of readonly, thus necessitating different syntax rules and support for automatic/traditional properties. Since there is a mechanism -- using traditional properties with only a getter defined AND a readonly backing field as in the referenced question -- I see no point in mucking up the property syntax and potentially introducing confusion for something with a fairly easy and straightforward implementation using the current language constructs.
If the propert has a private set, then it is readonly from the outside world, i.e:
string _name;
public string Name
{
get{ return _name; }
private set { _name = value; }
}
Or, it can be made readonly if it doesnt have the setter at all, i.e.:
string _name;
public string Name
{
get{ return _name; }
}
In C# 6, auto properties can be readonly
https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-6#read-only-auto-properties