Read-Only Computed Property vs. Function?

How do you decide if you want a Read-Only Computed Property (i.e. only the Get method implemented) or just a normal Function? For example, say you have a class Person that has FirstName and LastName properties. Do you create a Read-Only Shared Property or Function named FullName returning FirstName + " " + LastName?

Why do you want it to be shared?

If it was a shared method you would have to pass in the instance and I don’t think a shared computed property could be made to do that at all…

So you want either a regular class method or computed property.

The method can be overridden while the property can not (though it can be shadowed)

The Computed property would be VERY SLIGHTLY faster because it’s not virtual while methods are.

Ug! I didn’t mean to say Shared. I meant to say Computed… That happens all too often to me, I am thinking one thing and type another :-/

Now, that aside, thanks for the comparison of a Function vs. Read-Only Computed Property!

If you want it Read-Only then leave the Set method empty. The compiler should report an error if anything tries to write to the property.

Hope this helps. :slight_smile:

I think Jeremy question is about the pro and cons of using a Function vs. a Computed Property with Getter only.

Can’t say nothing about performance (but what Karen said makes sense), however mostly depends on what you have to do with your class. If you plan to override a method, you must use a the function. Yes you can shadow a property, but since it’s not virtual, this is a bad thing that may lead to very nasty bugs.

Oh, wow, you’re right; I definitely misread that. :stuck_out_tongue:

I agree with Massimo, though, and find Xojo fights shadowed properties. But, overloading aside, I use Computed Properties if I plan on using both get/set methods. It just organizes my code better than having two methods for each direction.

@Karen Atkocius, Just a FYI, I benchmarked the exact above scenario and a function call was faster. Performing 1,000,000 iterations:

* Call via Read-Only Property: 0.751049 seconds
* Call via Function: 0.733211 seconds

Now, that is well within the margin of error for benchmarking, but it does indicate no significant performance advantage for either. Also… I found during this exercise that when profiling is on, calling a method is MUCH more expensive than calling a property. I am talking about 3 seconds vs. 730ms. So, profiling this code does not help. I reverted to using Microsecond based timing.

[quote=18217:@Jason Adams]Oh, wow, you’re right; I definitely misread that. :stuck_out_tongue:

I agree with Massimo, though, and find Xojo fights shadowed properties. But, overloading aside, I use Computed Properties if I plan on using both get/set methods. It just organizes my code better than having two methods for each direction.[/quote]

Shadowing properties is a guaranteed recipe for pain and suffering in the future.
Try this very simple exercise
Create a class - Class1 and add a public property - Untitled as integer
Create two new subclasses - CustomClass1 and CustomClass2 both with a public property - Untitled as integer.
So now you have two custom subclasses that shadow the super’s property.
This simple code, when you run it in the debugger, shows why shadowing is problematic as this definitely does NOT do what you expect based on a simple read of the code.

[code]dim ctmp as Class1

ctmp = new CustomClass1
ctmp.untitled = 123
dim ctmp1 as CustomClass1 = CustomClass1(ctmp)
dim i1 as integer = ctmp1.untitled

ctmp = new CustomClass2
ctmp.untitled = 234
dim ctmp2 as CustomClass2 = CustomClass2(ctmp)
dim i2 as integer = ctmp2.untitled

break[/code]

IF you want subclasses to be able to override the supers implementation use a method pair - if not then it’s a toss up.

Use a regular property if you are simply setting or returning a value without calculation or validation. There is no need to complicate things.

Use a computed property if you’d like the result to show up in the debugger (remember, the debugger will force the Get code to run when you are looking at those properties), and either Set or Get needs computation of some sort.

Use a function if you only need to make the value of an otherwise private property available outside the class. The value of the private property will be available in the debugger so there is no need to expose it twice.

Use a function if you only need to set a private property or properties, with or without computation. In other words, if you are only going to use the “Set” portion of a computed property, use a function instead. There is no benefit to making a computed property here.

(This isn’t meant to be an exhaustive list of rules, merely the guidelines I use.)

In the example you site, I’d use a the Get portion of a computed property so FullName will show up in the Debugger.

[quote=18239:@Kem Tekinay]Use a regular property if you are simply setting or returning a value without calculation or validation. There is no need to complicate things.

Use a computed property if you’d like the result to show up in the debugger (remember, the debugger will force the Get code to run when you are looking at those properties), and either Set or Get needs computation of some sort.

Use a function if you only need to make the value of an otherwise private property available outside the class. The value of the private property will be available in the debugger so there is no need to expose it twice.

Use a function if you only need to set a private property or properties, with or without computation. In other words, if you are only going to use the “Set” portion of a computed property, use a function instead. There is no benefit to making a computed property here.

(This isn’t meant to be an exhaustive list of rules, merely the guidelines I use.)

In the example you site, I’d use a the Get portion of a computed property so FullName will show up in the Debugger.[/quote]

And consider whether you want your “property” to be virtual or not - then you have to use a get set pair of functions :stuck_out_tongue: