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.

Caveman

+1. This used to bug me in my early days of VB.NET. I've thankfully got over it now. – Udela

Answer 1

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.

Bury

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.

Bolan

For me is more than that - it's a data versus action relationship. Your object can perform a call to the database, but the data on the database is not a property of the object. For instance, your application could build an array of costumer objects from the database, and these would represent the actual model of the data, so their properties would be their own, and between other characteristics, this costumer would be serializable, while the database wouldn't. Besides, properties should never cause exceptions, and data access, native interop, etc, aren't safe. Just my 2 cents. – Hideaway

Answer 3

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

Cairistiona

Answer 4

The whole property thing was - probably - conceived 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 2000s for data access. This to avoid publicly exposed variables.

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

Undercut

+1 those always looked weird to me and some insist on writing UML like that, I find it less readable to see lots of GetSomething and SetSomething. – Hideaway

Answer 5

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

Hamper

Answer 6

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).

Kylie

Answer 7

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.

Intermarriage

...Because properties are the state. – Hideaway

Answer 8

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()

Helmholtz

Answer 9

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.

Contempt

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.

Soupspoon

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.

Rocca

All indexes in C# are like index[0] AFAIK. – Hideaway

Answer 12

I just realized that you can send parameters in a property exact same way you do it with methods. This implies you can write something like:

Private _ClientName As String

Public WriteOnly Property ClientName(isValid As Boolean) As String
    Set(value As String)
        If isValid Then
            _ClientName = value
        End If
    End Set
End Property

And then you can write this:

ClientName(debt = 0) = "Richard"

Or here is another idea to validate the text set to any label control:

Public WriteOnly Property OnlyNumbers(label As Label) As String
    Set(value As String)
        If Double.TryParse(value, New Double) Then
            label.Text = value
        End If
    End Set
End Property

Then you can use it like this:

OnlyNumbers(lblTotal) = debt

What I am not sure is if this is considered a "good practice" or at least a "correct" use of a property.

Directed