Readonly property vs function

[fred]

With a Class is there any difference between a readonly property and
function besides having to use Get/End Get.
Are there any performance/resource advantages for either.

Thanks
Fred

 

[Ken Tucker [MVP]]

Hi,

With a function you can pass in arguments and calculate a result. A
readonly property only returns a value.

Ken
---------------------
With a Class is there any difference between a readonly property and
function besides having to use Get/End Get.
Are there any performance/resource advantages for either.

Thanks
Fred

 

[fred]

Surely, I can have arguments on a property and calculate a result

Public Readonly Property Calc(ByVal X as integer, ByVal Y as integer) as
long
Get
Return X * Y
End Get
End Property

 

[Jay B. Harlow [MVP - Outlook]]

Fred,

With a Class is there any difference between a readonly property and
function besides having to use Get/End Get.

I normally use properties for a 'value' or 'attribute' a noun, something
that describes the object. (I'm using attribute here to mean an OO
attribute, not a System.Attribute class)

I normally use functions for 'actions' or 'behavior' a verb, something that
the object does.

Also you can using data binding to bind to a property, while you cannot bind
to a function.

Are there any performance/resource advantages for either.

Not really as a Property is effectively a function in the IL.

I find it better to write "correct" programs then to worry about
performance. By "correct" I mean OO and use the correct tool for the correct
job (for example: a property for attributes and functions for
behavior/actions). Remember that most programs follow the 80/20 rule (link
below) that is 80% of the execution time of your program is spent in 20% of
your code. I will optimize
the 20% once that 20% has been identified & proven to be a performance
problem via profiling (see CLR Profiler in my other message).

For info on the 80/20 rule & optimizing only the 20% see Martin Fowler's
article "Yet Another Optimization Article" at
http://martinfowler.com/ieeeSoftware/yetOptimization.pdf

Hope this helps
Jay

 

[Tom Dacon]

Curiously, the VB compiler doesn't hurl on this code, although it does
violence to the distinction between properties and methods.

Object-oriented theory considers a property to be a representation of some
notion of the state of an object, and a method (function or, in VB, sub) to
represent some behavior of the object that the method carries out.

A property may be simply a means of exposing the value of a state variable,
such as a string or numerical value held in the object's instance memory, or
it may be a transformation or calculated result based on the state of the
object. For example, you might have a Temperature class, with properties
named Fahrenheit and Centigrade. The class holds a single data field
containing the temperature value (in a representation that's no one's
business but that of the class - maybe it's in Kelvin), but returns the temp
in Fahrenheit or Centigrade by performing a calculation on the internal
temperature value.

By convention, a class that contains a list or collection of other objects
may expose an indexed property like Item, where a single input argument
represents the index in the contents, and the return value of the property
is the object at that location in the collection. This is about the only
parameterized property that the theorists approve of.

So, in general, properties don't have arguments, except for indexers.
Functions and (in VB) Subs may or may not, depending on their design.

HTH,
Tom Dacon
Dacon Software Consulting

 

[Jonathan Allen]

Yea, the IDE will constantly call your Get method.

As a general rule, you should be able to call a Property Get multiple times
with no side-effects. If the method actually does something, then use a
function.