On Propertiness

I’m not sure thats a word – propertiness

I’m using it to describe something that acts or behaves as a “property”

What defines something being a “property” ?

C# uses

A property is a member that provides a flexible mechanism to read, write, or compute the value of a private field. Properties can be used as if they are public data members, but they are actually special methods called accessors. This enables data to be accessed easily and still helps promote the safety and flexibility of methods.

https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/properties

There’s no specific requirement that a property be a simple type or a computed property – just that it has the ability to be read, written or possibly can access a private member.

A property could be implemented in Xojo using :

  1. a simple type like an Integer, Color, etc
  2. a computed property
  3. a pair of methods

Each has pro’s an cons

A simple property allows you to quickly and easily add a some setting for whatever you are adding this to. But, you cant easily make such a property read only or write only. And your code wont notice when this is set since there’s no event or anything to tell you it has been set. Subclasses cannot “override” this kind of property but they can “shadow” it.

A computed property is a simple set of get / set methods that are associated with the property. The setter has an implied parameter, value, that is the same type as your computed property. The getter has no such parameter and returns a value that is the same type as the computed property. The upside to this kind of property is now you have a place to put code to react to changes in the value, or to know when something accesses the value by putting code in the getter. Subclasses cannot “override” this kind of property but they can “shadow” it. This often has a protected or private backing variable that actually gets set or read – but not always as it may be derived from some other data held internally like the ubound of an array, number of rows in a listbox, etc.

A pair of methods, one define to return the value of whatever type and one to set the value, using assigns, are almost identical to a computed property. The biggest difference here is that, because methods ARE virtual this kind of property can be overridden by subclasses if they simply implement one or both of the methods that define the property.

Perhaps the most unique and useful aspect of these different types is that, in code that uses the property, you dont have to care what implementation is used. And, in code that creates & defines the property you can safely switch from one type to another as long as you maintain the same API (ie/ if a property is initially readable & writable then you have to maintain that when you switch to a different style otherwise code that expects to be able to write that property will no longer compile)

The upside to the last style is that the means you can “define properties” on an interface. Since a property isnt a specific implementation but a behaviour an interface can define the getter & setter and then any implementors of that interface now can expose that property with whatever custom implementation they need to implement.

Have fun !