Read only computed property?

General
1

I how do you define a read only (just get) computed property?
If I define a computed property through the IDE and try to delete the Set method the whole property disappears.
If I don’t implement Set then is this the same as making it read only?

2

Yes.

3

I would recommend making it a regular method that returns the value. That way the compiler will complain if you try to set it.

4

The compiler will also complain if you try to set a read-only property.

5

You learn something new every day. It really does make it “read-only”. Nice job, Xojo!

6

I’ve really been trying to wrap my old brain around Object Oriented methodology and design …
One of the first rules I learned was to never give direct access to your properties, that Getters / Setters should ALWAYS be used.
I thought this was over kill but having getters and setters seems really to have other advantages.

Any thoughts on this?

7

[quote=63305:@Brian O’Brien]I’ve really been trying to wrap my old brain around Object Oriented methodology and design …
One of the first rules I learned was to never give direct access to your properties, that Getters / Setters should ALWAYS be used.
I thought this was over kill but having getters and setters seems really to have other advantages.

Any thoughts on this?[/quote]

The way the Xojo language works is that you can start off with simple properties and then, if you find the need to, make them computed properties with no changes in syntax of how it’s used. Other languages don’t work like this and encourage getters/setters up front.

8

This is one of the things that makes the language appealing
Consumers of a class never need to be aware that you have swapped from public properties to computed ones or get /set method pairs

9

Getters and Setters are not unique to Xojo … A friend of mine who was trying to teach me OO was teaching me this in Python.
I never got the rational of why he recommended/insisted always using getter / setter over a public property.

What I’ve learned is:

  1. You can change the from a public property to a computed property and not change the interface.
  2. You get rid of the getter and it converts it to a read only property.

What other advantages are gained by using getters / setters?

10

What about serialization and introspection?
You can’t override a public property that isn’t a computed property… (Remember my trouble with Shell Mode?)

Why use getters and setters

11

[quote=63311:@Brian O’Brien]What about serialization and introspection?
You can’t override a public property that isn’t a computed property… (Remember my trouble with Shell Mode?)

Why use getters and setters[/quote]

You can’t override properties of any sort. They’re never virtual and you end up shadowing instead of overriding.

12

i never use computed property. When should i used computed property instead of the normal property.

does a read only computed property similar to constant?

13

I would like to say: always - but this is not practical.
In general one could say: your code gets safer, the more you hide the state of an object. The more you narrow down the possibility of a state change from the outside of an object, the better. It’s called encapsulation or information hiding or need to know basis.
Without a setter any other object can change the value of a public property without the object knowing about. With a setter, you are informed and you can act on it. For example by recalculating other (dependent) properties within the object, or in a RectControl you can invalidate it and therefor have the control redraw itself, or you can raise an exception if the assigned value is unacceptable.