Björn Eriksson:

Maybe not fully since Xojo is not good with Properties in Interfaces :frowning:

Thom McGrath:

Interfaces are the closest we can get, but that doesn’t help with properties.

What stops Xojo adding properties to interfaces? After all, Swift has Interfaces WITH properties (they call them Protocols) … :thinking:

Lack of a compiler engineer?

Xojo’s interfaces are patterned after legacy Java ones - no properties

And they would need a compiler engineer to revamp this
I do not believe they have one

Can we add constants to Xojo interfaces? I never tried, so it’d blow my mind to learn that was possible. Enums and delegates would be nice additions too.

Went to go check for you. Only Methods and Notes.

Screen Shot 2022-04-26 at 10.32.16

You can emulate properties by means of getter/setter methods:

Interface MyInterface
    Function Value() As Integer
    Sub Value(Assigns v As Integer)
End Interface

And if the class already has a property with that name you can use the Implements keyword to bypass the conflict:

Class MyClass
Implements MyInterface

    Dim Value As Integer ' the class property

    Private Function GetValue() As Integer Implements MyInterface.Value

    Private Sub SetValue(Assigns v As Integer) Implements MyInterface.Value

End Class

Dim foo As MyInterface = New MyClass
foo.Value = 1

Xojo’s are API only really

A compiler engineer might be necessary to add constants etc :stuck_out_tongue:

Computed properties really should work with interfaces if things were done correct.

Normal properties I would say should not.

Computed property is function in reality so then full-fills all purist rules on implementation and interfaces.

A computed property still needs to save the value (so it can be used for the getter whether it shows the variable or not) - so it is not just a function.

And if computed properties can be used then there is no reason for normal properties not to be used too.

The data store that backs the getter/setter should be an implementation detail of the class(es) implementing the interface.

I agree. No reason computed properties shouldn’t be supported.

Why? Swift can do it (called Protocols) so why not Xojo?

Because the backing datastore doesn’t necessarily have to be a property of the class.

That would seem a very bad design. Every time you add an interface to a class you have to remember to add the data stores to the class too - not exactly encapsulation as we know it.

Furthermore the biggest advantage of interfaces and protocols is that they are types in their own right and cut straight across the class hierarchy - putting the data store into the class that implements the interface seems like a weird hybrid that isn’t even necessary if you turn interfaces into proper protocols.

I think the point is they make it so the implementor can still choose how to implement the functionality specified but the property which is true for any method specified in an interface

Interfaces specify “an API contract” - not implementation - in the Java world and RB/Xojo has very much followed that same style

You have to remember to implement the methods too. That’s what implementing an interface is.

not exactly encapsulation as we know it.

I suppose it depends on whether you’re hiding the implementation behind an interface, or hiding the interface behind the implementation.

There is a difference between implementing and adding code (essentially overtiding an empty method in the case of interfaces/protocols).

With your way you can forget to do it and end up with a “This item does not exist”. You can even end up with hard to track bugs if you use the interface as a type and with casting refer to a non-existing property (which should result in a crash even though the compiler does not complain)

IF you. were able to add properties as well as method the property would be part of the things you MUST have in order to implement the interface
You literally couldn’t have the property not exist
Same as if now you claim to implement an interface e then delete one of the required methods