How do I go about creating something similar to the Read Only properties in the Framework?
Specifically, I have properties in a module that code within the module needs to be able to change but client code outside the module should only be able to get the value of them. In essence, I need a computed property with a Global Get method and a Protected Set method but this doesn’t seem to be directly possible.
How to I accomplish what I’m trying to do here?
A computed property that only has the getter implemented
The class / module itself can manipulate the backing property
Everything outside this can only use the getter
What backing property? Example please
Right-click your property and select “Convert to Computed Property”. This will add Set and Get children to your initial property when you expand it. Expand it and click Set, then comment out the code within. Your property is now read-only.
See feedback cases:
(https://xojo.com/issue/49428)]49428 Add Support For Read-Only Class Properties
(https://xojo.com/issue/37712)]37712 Displaying access mode (readonly or read/write) of computed properties
And I would appreciate if we could mark for properties that setting is private, so we avoid the setter method.
Note that you can now set the value within the class/window/page/etc parent of the property by using the backing property. If your original property is named ReadOnly then your backing property will be named mReadOnly
[quote=437250:@Christian Schmitz]See feedback cases:
<https://xojo.com/issue/49428> Add Support For Read-Only Class Properties
[/quote]
I’d truly be surprised if anything were done with this beyond saying “use a computed property and only implement the getter”
More badges in the navigator ??? please no …
I thought about an attribute.
Instead of the overhead of a computer property, we could have an attribute saying setter is private for a regular property.
This would make a ton of things quicker in xojo.
A “computed property” should have a getter, or a setter, or both. Marking a setter as “disabled” or not having one, should not generate any setter code, and writing myComputedProp=value should raise a “no setter defined for such property” compiler error. This is different of a void setter failing silently due to not assigning the value because it has an empty setter code.
The workaround I use is emulating it with a method. Private Function myIntegerProperty() As Integer, for example.
The downside to methods is that they dont show in the debugger and can be overridden by subclasses.
[quote=437254:@Christian Schmitz]I thought about an attribute.
Instead of the overhead of a computer property, we could have an attribute saying setter is private for a regular property.
This would make a ton of things quicker in xojo.[/quote]
Such an attribute would have to be something enforced at compile time by the compiler to see you never try to set the property
That’s a decent sized change
As a true American, I don’t want any language to tell me what to do or not to do!
Oh wait, I am French! 
I dont expect anything will occur about this since there are ways to achieve read only properties with other existing language constructs
I do expect, not soon, but because the current design is an outdated design that needs fixing/update. A property usually must have a Type (Int, String, etc) an optional init value ( 123, “asdf”, set before the initializers and the constructor()), a scope (public, private, …), a mutability declaration: read write/read only (also called mutable or not), and optionals initializer code (can be optionally lazy, it means, called after other non lazy inits, so you can use other non lazy values for calcs in lazy ones), getter code (overrides the system access to the stored value) and setter code (overrides the system attribution to the stored value, not present in immutables). An immutable property does not have a setter, a myProp=v gives you a compiler error.
We should not need a “back property” to store the current property values. Inside the class code, we could have some expression or operator to access the direct stored value, like myProp.Value, or some operator like Prop myProp = v; when you say just myProp, you call its setter/getter codes, but myProp.Value (or some operator to direct access myProp only accessible inside its Class) we bypass the getter/setter codes and go directly to its stored value. No need to have 2 properties, theProp (to handle code) and mTheProp (to store) anymore.
That would be great if the end result was just a read/only property… but how would you set or control its value?
with the Getter/Setter Computed Property method the containing class can manipulate the “backing value”
but if you get the property a “readonly” attribute, then you basically have what is currently a “constant”
In addtion, the Getter/Setter method allows the app to perform various additional actions based on if the backing variable actually changed, or met certain other criteria. Rarely do I have a Setter that is simply
mVar = newValueYou didn’t read correctly. I described all the scheme for EVERYTHING I miss and we can find in other languages.
It includes immutables, getter, setter, inits, laterinits, etc
A constant is not a proper construction for a property because a constant is constant (like “123”) and a immutable property can call a getter code that sometimes returns “123” and sometimes “456”. But if you try myvar = NewValue you get a compiler error, in the same way you had if you tried it in a constant.
[quote=437369:@Rick Araujo]I do expect, not soon, but because the current design is an outdated design that needs fixing/update. A property usually must have a Type (Int, String, etc) an optional init value ( 123, “asdf”, set before the initializers and the constructor()), a scope (public, private, …), a mutability declaration: read write/read only (also called mutable or not), and optionals initializer code (can be optionally lazy, it means, called after other non lazy inits, so you can use other non lazy values for calcs in lazy ones), getter code (overrides the system access to the stored value) and setter code (overrides the system attribution to the stored value, not present in immutables). An immutable property does not have a setter, a myProp=v gives you a compiler error.
[/quote]
The consumer of any class/module should not need to know whether it is or is not a method pair, get / set accessors on a computed property or a bare property
And all of the things you state are possible today given the existing language
The framework actually uses this and its trivial to implement
[quote=437369:@Rick Araujo]We should not need a “back property” to store the current property values.
[/quote]
You may not always require one - its optional
And now we’re back to “this will take compiler changes” since its not already part of the grammar of Xojo and I doubt they will happen “soon”
There’s literally no reason for it to since you can accomplish all this already
Async Await would be a better use of that time IMHO
I know. That’s why I said:
Generics, Async/Await, Futures. This order.
Much more time than a property overhaul. But very desired.