There are several requests for class interfaces to support properties dating back up to 15 years in various states of closure or just simply being ignored by Xojo e.g: 19070, 20443, 5938, 59033 and 74262.
Currently, you can only add methods to a class interface, these are there enforced / added by the IDE when you create a custom class implementing your interface.
There are many times when I require classes to possess a property as part of an API I’m creating. The current implementation of interfaces doesn’t support properties which means you need to add a method pair instead.
Consider the situation where I would like a collection of classes to have the property Name. For this to be part of an interface in Xojo I would need to create two methods to simulate this:
Public Function Name() As String
End Function
Public Sub Name(value As String)
End Sub
Implementing this interface would also require my classes to have a third (private) property, say mName that would hold the actual name that I could manipulate in the above two methods.
If you are building an API with many classes implementing an interface (in my current project I have 88 classes implementing a single interface) you would need to repeat the implementation of this 88 * 2 = 176 times! It is a colossal waste of time.
Most other languages that implement interfaces support properties and methods and I think 15 years is enough time to wait for Xojo to do the same.
now that the api change (mess) is on it’s way out, that android is almost out, it is time to enforce the xojo base language, like the properties for class interfazces, or the ability to have classes inside external modules…
in example for the name for all classes it is somehow a propertie of the base class which is adressed by super =
There are situations when classes, which do not share the same super, can be used via interfaces to make things easier. So in these situations you should be able to add properties to an interface.
Not sure if I’m following the idea, but you guys want, in Xojo terms, “computed properties” in the interface, correct? Because interfaces are not intended for data, just “accessors” to the data in the class where the user will implement it (much like methods).
I’m not aware that Swift allows what you are saying (regular properties).
AFAIK Swift implements Property accessors (Getters/Setters) in Protocols as Computed Properties are in Xojo.
The only thing an interface would define is:
“You are required to have an property of type x”
If it’s an normal property or computed should be free to be chosen if this can be created by xojo.
It allows to circumvent shadowing properties that would otherwise cause issues.
I also would suggest to let people add a property to the interface definition. Then the implementer of the property should be able to define whether they use a regular property or a computed property.
Method pairs don’t work with the existing property handling in Xojo as far as I know.
Interfaces/protocols works this way by definition, the talk to the Class, not the storage, the storage (if any, because it can be virtual) the designer of the class will take care.
A protocol can require any conforming type to provide an instance property or type property with a particular name and type. The protocol doesn’t specify whether the property should be a stored property or a computed property — it only specifies the required property name and type. The protocol also specifies whether each property must be gettable or gettable and settable.
This is the most flexible and error free solution.
