The interface methods in the classes implementing the interface do not automatically update when you add more methods to the interface at a later date, or change the method definition (for example add another parameter). Is there a good reason for this or should this be considered a bug?
I did/do have a feature request about adding methods to implementors if you added to the interface see feedback://showreport?report_id=2523
Not sure about changing the parameters or something like removing a method to be honest
Those could have other complications like if one method is used to satisfy two interfaces then altering it breaks the other interface and the same if you remove it
They’re admittedly edge cases but someone will hit them - they always do 
It just seems weird as an Interface is an object in its own right, eg you can do
If c IsA Interface1 then
or
Interface1( Listbox1.RowTag ).someMethod
so for my feeling it should update.
Interfaces are data types
And making it so when you add a method to an interface all implementors then get that method added to them makes sense since they state they implement the now altered interface
Alteration of an existing method on an interface is trickier
suppose you have
Interface Foo
sub bar()
End interface
Interface Baz
sub bar()
End interface
Class foobar
implements foo, baz
sub bar()
end sub
end Class
which is legal
One method can / could be used to implement both methods in those interface since all it has to do is match the signature
If we alter the BAR signature in Foo should we update the bar implementation in class foobar ?
If we do we break the implementation of at least one interface. Its not clear to me what the correct thing to do is in this case
Removing a method from an interface poses similar issues
Slightly off topic… I have never used interfaces in Xojo… but with what I say above, and what I now know about Swift… Is it correct to assume the an Xojo Interface is identical in function to a Swift Protocol?
As in Swift I would see something like this
protocol Foo : NSObjectProtocol {
func bar()
}
protocol Baz : NSObjectProtocol {
func bar()
}
class foobar : foo, baz {
func main() {
sub bar()
}
}
Not that EXACT Swift syntax… but same vein?
Turns out I am using Protocol/Delegates and Enums both 1000x more in Swift than in Xojo and it makes things much simpler in a lot of respects
Enums in Swift are vastly superior to Enums in Xojo sadly.
I use Interfaces all the time and mostly like them. I do wish there was a way to declare a property in an interface rather than resorting to setter/getter methods though.
Protocols are about as close as you get - but they can be completely or partially implemented which you cannot do with an interface
If you claim you implement the interface you implement the whole thing
No less
+100 there… you can have a single enum perform mulitiple related things
I probably could have done this differently… but this fit the apps requirements, and shows the flexiblity
public enum HighlightColor : Int {
case Green = 0
case Blue = 1
case Cyan = 2
case Magenta = 3
case Orange = 4
case Red = 5
case Yellow = 6
var description : String {
switch self {
case .Green : return "Green"
case .Blue : return "Blue"
case .Cyan : return "Cyan"
case .Magenta : return "Magenta"
case .Orange : return "Orange"
case .Red : return "Red"
case .Yellow : return "Yellow"
}
}
var color : UIColor {
switch self {
case .Green : return UIColor.green
case .Blue : return UIColor.blue
case .Cyan : return UIColor.cyan
case .Magenta : return UIColor.magenta
case .Orange : return UIColor.orange
case .Red : return UIColor.red
case .Yellow : return UIColor.yellow
}
}
}
Interfaces are about behaviour
Not implementation
If you could use computed properties for interfaces that would be about the right approach
BUT - there are technical reasons why methods are how you have to do this.
Methods are virtual
Properties are not
Making properties virtual would, I think, be required to make interfaces capable of defining properties. And that requires a compiler engineer
FWIW Xojo makes it invisible to the consumer of a class that a “property” is
- a publicly exposed property
- a computed property
- a get / set pair using assigns
few languages do this and I find it to be among the most useful things Xojo does
Oh that property needs to be virtual so subclasses can override it !?
No problem - turn it into a get set pair and you should find no code that uses it ever has to change
Xojo enums are more like old C++ enums than any Swift enum
And they were restricted to integer types
a compiler engineer would be required to change this
CER = shorthand for “compiler engineer required”… as this seems to be an often used term lately 
2 Likes
Most of “API 2” is window dressing (I’ve said this before)
We could have achieved most of this on our own with subclasses & defining our own events and then just use our subclasses instead of the built in ones.
The things that really matter - bug fixes in the C++ framework code, fundamental language changes and additions like Generics - arent things that API 2 will or can do anything about
because its not altering the really low level things
The single exceptions to this are the addition of VAR as a synonym for DIM (which is about the MOST trivial change to make in the compiler) If it took more than 5 minutes to add there was something wrong as DIM was a very simple item in the grammar from what I recall
That and moving folderitem to newer apis on macOS are about the only really low level changes that occurred
MOST of folderitem was already updated in the iOS framework and needed to be moved over & adopted for desktop - there was work required there
Heck even API 1.0 folderitems got this update because - wait for it - the same C++ code underpins them both 
1 Like
+1 for CER 
True but I dislike it for two reasons:
- Adds a method call which can have performance implications in tight loops (think graphics and physics engines)
- Can lead to duplication of code by writing getters/setters which could be avoided with a single property.
Regarding a compiler engineer - do you think it’s the case that Xojo Inc is choosing not to hire one or that it’s the type of skill set that is hard to find?
Right - but then IF you want to dictate that it BE an actual property then an interface is the wrong thing
Computed properties would be about the only kind of property I would see making sense since they really are just a get / set pair of methods and so making them virtual shouldnt be rocket science
IF you want to dictate the implementation thats not an interface
Interfaces are about “behaviour” - not specific implementation details
Regarding a compiler engineer - do you think it’s the case that Xojo Inc is choosing not to hire one or that it’s the type of skill set that is hard to find?
Probably a bit of both leaning a bit harder on the skill set is hard to find
Mars Aaron and Joe - the last 3 compiler engineers - were unusual folks in that they knew both C/C++ very well AND Xojo as well and so could bridge between the two easily.
And they also happened to like delving deeply into compilers and such (the arcana that requires is truly confounding when you het to talking about phi-nodes etc)
Anyone who could fill that role is probably already working, busy as hell, and expensive
I would argue that you should have BOTH methods in foobar
Interface Foo
Sub bar()
End interface
Interface Baz
Sub bar()
End interface
Class foobar
implements foo, baz
Sub bar() // from foo
Sub bar() // from baz
End Class
and an error warning that Xojo can’t decide which one to use (as with any duplicate method). So update the name of one of the methods in the interface and voila (if the naming change propagates).
Why? Delete the one from the interface that deleted it and keep the other one:
Interface Foo
// removed sub bar()
End interface
Interface Baz
sub bar()
End interface
Class foobar
implements foo, baz
// removed Sub bar() // from foo
Sub bar() // from baz
End Class
The only problem would be if Xojo does NOT keep track of which interface method comes from which interface (in which case just rebuild it internally).
I would argue that you should have BOTH methods in foobar
I dothere IS a way to say “this method implements that method from that interface” but this IS perfectly legal to have one method that both interfaces use
There is nothing semantically or syntactically invalid about it
Having two with the exact same signature IS a compilation error already as it would be totally ambiguous
Why? Delete the one from the interface that deleted it and keep the other one:
uh … which bar do you remove ? and why ?
There is NOTHING in the signature that tells you which one came from where so how do you decide ? This goes back to “its perfectly legal to have a single method defined on two interfaces and only one implementation and BOTH interfaces are properly implemented”
Once you accept that this IS legal (not JUST in Xojo but in other languages as well) then “which one to remove” IS a problem since they are not tagged in any way that is “permanent” or hidden away from the user
Nor should they be because that tagging would/could be incorrect (in the weird case I’ve givent)
Even the former compiler engineers agreed its legal and so the removal issue IS real
Adding to an interface SHOULD be very doable
I don‘t see a problem with tagging behind the scenes which method comes from which interface. Come to think of it, you could even have the interface as a parameter of the method.
But even if that is a problem then it is up to the programmer to make sure to name the methods accordingly. The compiler spits out a warning anyway, and then you rename manually.
the way interfaces work now IS correct
its consistent with how the Xojo language was designed and with other languages that have such capabilities on which Xojo’s was modelled
and thats where the conundrum comes from
adding to either interface and then adding to the implementors would work
removals and parameter alterations are much trickier because of this ability to have one method satisfy more than one interface