Creating Read Only Properties

  1. 4 weeks ago

    Bryan D

    May 19 Pre-Release Testers, Xojo Pro

    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?

  2. Norman P

    May 19 Pre-Release Testers, Xojo Pro great-white-software.com
    Edited 4 weeks ago

    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

  3. Bryan D

    May 19 Pre-Release Testers, Xojo Pro

    What backing property? Example please

  4. Anthony C

    May 19 Pre-Release Testers, Xojo Pro GraffitiSuite Developer

    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.

  5. Christian S

    May 19 Pre-Release Testers, Xojo Pro, XDC Speakers Germany

    See feedback cases:

    49428 Add Support For Read-Only Class Properties
    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.

  6. Anthony C

    May 19 Pre-Release Testers, Xojo Pro GraffitiSuite Developer
    Edited 4 weeks ago

    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

  7. Norman P

    May 19 Pre-Release Testers, Xojo Pro great-white-software.com
    Edited 4 weeks ago

    @ChristianSchmitz See feedback cases:
    Feedback Case #49428 Add Support For Read-Only Class Properties

    I'd truly be surprised if anything were done with this beyond saying "use a computed property and only implement the getter"

    @ChristianSchmitz Feedback Case #37712 Displaying access mode (readonly or read/write) of computed properties

    More badges in the navigator ??? please no ...

  8. Christian S

    May 19 Pre-Release Testers, Xojo Pro, XDC Speakers Germany

    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.

  9. Rick A

    May 19 (Brazil. GMT-3:00)
    Edited 4 weeks ago

    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.

  10. Rick A

    May 19 (Brazil. GMT-3:00)
    Edited 4 weeks ago

    The workaround I use is emulating it with a method. Private Function myIntegerProperty() As Integer, for example.

  11. Greg O

    May 20 Xojo Inc

    @Rick A The workaround I use is emulating it with a method. Private Function myIntegerProperty() As Integer, for example.

    The downside to methods is that they don’t show in the debugger and can be overridden by subclasses.

  12. Norman P

    May 20 Pre-Release Testers, Xojo Pro great-white-software.com
    Edited 4 weeks ago

    @ChristianSchmitz 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.

    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

  13. 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! :-)

  14. Norman P

    May 20 Pre-Release Testers, Xojo Pro great-white-software.com

    I dont expect anything will occur about this since there are ways to achieve read only properties with other existing language constructs

  15. Rick A

    May 20 (Brazil. GMT-3:00)
    Edited 4 weeks ago

    @Norman Palardy 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.

  16. Dave S

    May 20 San Diego, California USA

    @Rick A I do expect, not soon, but because the current design ....

    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 = newValue
  17. Rick A

    May 20 (Brazil. GMT-3:00)
    Edited 4 weeks ago

    @Dave S That would be great if the

    You 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.

  18. Norman P

    May 20 Pre-Release Testers, Xojo Pro great-white-software.com

    @Rick A 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.

    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

    @Rick A We should not need a "back property" to store the current property values.

    You _may_ not always require one - its optional

    @Rick A 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.

    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

  19. Rick A

    May 20 (Brazil. GMT-3:00)

    @Norman P this will take compiler changes

    I know. That's why I said:

    @Rick A I do expect, not soon

  20. Rick A

    May 20 (Brazil. GMT-3:00)
    Edited 4 weeks ago

    @Norman P Async Await would be a better use of that time IMHO

    Generics, Async/Await, Futures. This order.

    Much more time than a property overhaul. But very desired.

  21. Newer ›

or Sign Up to reply!