What is the difference between readonly property and function in .net?

Question

Apart from an architectural point of view, i'm wondering if there is any difference in .net between a readonly property and a function. Are properties only conceptual wrappers around functions?

    Private m_Property As String 
    Public ReadOnly Property PropertyGet() As String
        Get
            Return m_Property
        End Get
    End Property

    Public Function FunctionGet() As String
        Return m_Property
    End Function

Disassembling IL shows that there's no difference apart from the name, but are there differences at another level? Is the getter just a function in short(!?)hand?

---

Edit: wow, i'm really sorry about not being able to mark multiple answers.

The first answer that pointed out the use of properties to serialize was the road to enlightenment since i had completely left this aspect out. Before that, the explanation of property vs function as "is" vs "does" felt arbitrary. Now, i grok it more.

I think the consensus on property being not time consuming stems from the "is"/serializable concept. If my property talks to a database to store the "is" value, it breaks in horrible ways.

Answer 1

yes, property are just a high level concept over the Set/Get methods.

Answer 2

The difference is more semantic that functional; a property getter is in fact a function under the hood. The difference is more that as a programmer, you often expect that calling a property getter is a very cheap operation, while calling a function could potentially be more expensive.

Note that this is not necessarily the case; you can very well implement very light-weight functions, and very heavy property getters, but as a rule of thumb, a property getter should typically do nothing much more than simply get the value.

Answer 3

A property is the same as a function. But a property indicates that you are getting (or setting) "properties"(Member Variables) of an object and that these getter/setter are not time consuming function that f.e. calculates something or queries the database. Therefor they are a useful syntactical sugar (if they're implemented correctly).

Answer 4

Property get/set is syntatcit sugar. Readonly in VB is just a way of specifying that you only want the get 'function'

it can then look like you should pass properties by reference (ByRef) to methods but as you point out it is a function not an actual type.

I do tend to use functions for getters when the operation is expensive, e.g. GetCustomersFromDatabase()

Answer 5

There's one important difference if you use data binding, you simply cannot bind to a method, you can only bind to properties.

Answer 6

The whole property thing was - probably - consieved to avoid getting a bunch of separate GetSomething(), SetSomething(var x) methods, which used to be the norm in, for example, Java in the early 2000's for data access. This to avoid publically exposed variables.

Believe me, those classes looked awful. I personally think the property concept is a great leap forward in readability and structure.

Answer 7

While a property may be implemented as a method behind the scenes the semantics between a readonly property and a method are different. A readonly property is not expected to have any side effects; whereas a method depending on the context can have side effects.

Answer 8

get properties are expected to be pure, and if you look into the .net Code Contracts, you'll see they assume getters are pure. Thus, calling a property get once, twice or 10 times shouldnt have any difference to the object, where as calling a method on an object, may lead to multiple changes to the objects state.

Answer 9

A property combines both concepts of fields and methods. In fact, a property is accesed like a field, but the underlying pieces of code are methods. The field part of a property allows you to access a value just like a field would do, though allowing you to trick this getter function and setter procedure, if I may say. Properties are most commonly used to control over a field value that is assigned or returned. And under the risk to repeat myself, they are accessed as a field.

On the other side, functions, procedures, both known as methods in OOP, are by definition routines to process the information. There need to be a process over an object or piece of information, for example, it is not rare to encounter a function's name like DoThis, DoThat... They can be used over fields or properties, but functions are known to impact more than just a field, or control a value over a field. Functions, by opposition to properties, can have multiple parameters, optional parameters, and even be generics!

I would like to add that, to my knowledge, a property cannot be anonymous, neither generic. Attention, I do not say that a property cannot return a generic, I say that the property itself cannot be generic. A function can be both anonymous, and generic.

In short, a property is a concept used over a field, to gain control over a field value, while functions are doers, we expect them to perform tasks, and not just assignments.

Answer 10

the keyword readonly just means "Dear compiler don't expect a setter" "and if i do so, punish me". This is a decision of VB syntax. Behind the scenes functions and property getters are the same.

Answer 11

The normal debug watch window for a class will show the values of non-indexed properties, but will not show the results of functions. One of my pet peeves with the StringBuilder class is that it does not have a property for the current string content, which makes the watch window much less useful than it would otherwise be.

Also, non-indexed properties, unlike methods, do not require a () after the name; I believe indexed properties in C# are required to use [] rather than () for their parameters.

Answer 12

I'd like to add, as a con for using properties, that serialization understands the concept of properties and uses them while it does not know anything about getter/setter methods. Plus, if you are using a property in a compact style like:

public int MyProperty { get; private set; }

you can spare quite a lot of lines of code from your source files, making them more readable.