Silent code breaking changes :(

Was helping a fellow Xojo user to try & sort out why updating to a new version of Xojo broke their code.

The code still compiled fine. But it just didnt work as expected any longer.

And it turns out that in some classes Xojo changed a get/set pair of methods, which can be overloaded by a subclass, into actual computed properties, that cant be.

They had subclassed the Xojo class and overloaded the method pair to do some custom things. And now, since properties are NOT virtual, all their customizations no longer work.

The trouble with this change is that it IS a silent behavioural change.
And it has the effect I wrote about some time ago – Virtual dispatch for properties

Worst of all there appears to be NO release note or change notice that this was done in the 2022r3.2 release cycle.

Here’s a tiny example of the issue

For starters this is the entire code in a console apps RUN method

Dim c As Class1MethodPair

c = New CustomClass1MethodPair

// given our current set up where Storage is a METHOD this will return the SUBCLASS value 

System.debuglog c.Storage


Dim cp As Class1AsProp

cp = New CustomClass1AsProp

// and now ?????????

System.debuglog cp.Storage

The ONLY difference between these sets of classes is the first implements STORAGE as a get/set pair of methods, which the cubclass CAN properly overload.

And the second Storage is a computed property.

The results wont be what you expect by looking at the code !

The change xojo made is exactly the same, changes behaviour silently, and appears to be undocumented

2 Replies to “Silent code breaking changes :(”

  1. That’s a serious bug. I suspect an engineer wasn’t aware of the overloadbility difference between methods and computed props and changed it either out of “code cleanliness” or because it makes debugging easier (the debugger shows values of computed properties).

    Either way, this should be seen as a regression that needs to be reverted – and the Xojo engineers need all be taught not ever to do that without a really good reason.

    I say that because I rely heavily on this overloading ability in my apps, and I had long wished that _all_ computed properties are turned into methods so that they’re all overloadable.

    1. I have to admit that I tend to believe it was simply done because “Oh we document this as a property and gee look its not really so lets make it one” without realizing the impact it MIGHT have

Comments are closed.