Is there any REAL difference between the following 2 items other than syntax?
VB Code:
Public Function GetString() as String return "hello world" End Function Public Readonly Property GetString() as String return "hello world" End Property
Printable View
Is there any REAL difference between the following 2 items other than syntax?
VB Code:
Public Function GetString() as String return "hello world" End Function Public Readonly Property GetString() as String return "hello world" End Property
Nothing, I think. They probably compile to the same IL.
"Property" is only there so you can pair up get/set clauses. I suppose it encourages clear coding style.
I think I read somewhere that you use Functions when the method does some operations like looking through an array, do something and then expose the result and you use properties when you just want to expose a variable. I must admit through that I am sometimes tempted to use functions, just like in Java where you have GetXXX and SetXXX functions. Actually I think the compiler actually generates Get/Set functions behind the scene.
That is what I figured.. I just wasn't sure if there was any clear reason to use one or the other...Quote:
Originally Posted by wossname
I will usually use functions for the type of example I posted...
Probably, the only real advantage for a property would be the ability to use a single function for Get and Set rather than two separate ones. In the case of ReadOnly, it may not make a difference.
The one way that it could make a difference would be if you had a variable that was exposed through a property (as opposed to a string literal like you used in your example). I have no idea whether or not this is done, but it would be possible that the property would execute faster if it returned an offset into the class to return the item, rather than incurring the overhead of a function call. That kind of optimization is probably not done in .NET, but I suppose it could be.
You can databind to the property but not the function/method.
you and your love for databinding!!!! :)
good point though...
so basically in SOME situations.. there are a few fundamental differences.. but for most cases they are pretty much the same thing... something in a class that returns a datatype.
True enough.
On the other hand, you have to consider maintenance. If you declare something as a property, it seems to suggest a type of behavior. Though you could do the same thing with functions, are you telling a third party the same thing with a method rather than a property.
Actually, what I just said makes a bit of sense to me, but not all that much. I can't support it further than that, but it MAY be a consideration.
no i get what you are saying, because something that is a function you KNOW is returning a value, but when its a property, you need to dig a little bit into the help or check the intellisense, (OR get a syntax error) to know that the property you are tring to assigning a value to is read only...
A property is supposed to represent some inherent attribute of an object, while a method is supposed to represent some behaviour of that object. The lines do become blurry at times, but if, from the outside, something looks like it could be represented by a simple variable then it should generally be a property. Look at the example of the Form.Visible property and the Form.Show and Form.Hide methods. They have the same result but one represents an attribute inherent to the object and the other represents a behaviour.
I agree, and I generally have a property be something that a user would expect to be a feature of the class, whereas a function is something that a user would expect to be a product of the class.Quote:
Originally Posted by jmcilhinney
Behind the scenes, some of the properties do some fairly extensive calculations, but they still are things that seem like they ought to be features.