The other day I was helping a friend with some code that worked fine in several versions of Xojo but then in a newer one wouldn’t compile
Seems he found a compiler regression Whether this _should_ have been caught by regression tests etc is an entirely different question.
It exists. And now his large project doesn’t compile.
The code this affects is old and has worked for many years.
And he’d rather NOT have to alter all of it to fix the issue.
Since the code in question is in a subclass he was not looking forward to making significant changes to it and having to retest all his changes
So how can he fix this compiler issue and NOT have to touch all the code that suddenly doesnt compile ?
There are several options
Of course he could “fix” the code in the class directly – not something he relished
Another option is to just NOT use a new version of Xojo that breaks things this way – not a great option if he wants to support Ventura & newer
There is at least 1 more that is fairly simple, testable, and does fix this without actually modifying the code in the original class 🙂
I’ll let you noodle on that until tomorrow.
2 Replies to “Fixing code by not touching it”
Change the offending class’ name, subclass it with the original class name, override the offending methods?
That might work as well – what we did I just posted about – we inserted a class in the inheritance hierarchy between the Xojo class and the existing subclass so we could expose the specific property ( the one mentioned in the bug reported I linked to) as a etch get/set pair which a subclass can then override
Comments are closed.