Inherited properties cannot be overridden

Getting Started
1

I was just wondering out of curiosity, is there a reason why Xojo prevents the overriding of properties in a subclass?

2

Can you give an example?

3

There isn’t actually overriding, just shadowing (which is bad, please don’t do that). It’s possible that computed properties could someday be made virtual, but then you could end up with a fragile implementation that depends on your superclass never changing their property to be non-computed (or to a getter/setter pair of methods).

4
  1. In a new project create a new class named “Class1”
  2. Add a property named “ABC” of type Integer to Class1.
  3. Now create a second class named “Class2” that has Class1 as its super.
  4. Add a property named “ABC” of type String to class 2
  5. Run the project and the error shows “This property shadows a property of a different type”.

Thanks for clarifying this Joe.

I’ve never attempted this, and never had a need to do so either. Myself and a colleague are just comparing Xojo with other languages, and he posed this question to me, and I wasn’t too sure how to answer him.

5

if you take a class like “TestGroup” from the Xojo Unit Testing. and you subclass it to add additional features. One of the properties of TestGroup is of type TestResults. But if you subclass TestResults too to add extra functionality, you cant tell your subclass of TestGroup to have the properties of your subclassed TestResults.

for instance.

TestGroup.CurrentTestResult is a TestResult

I would want it to be…

MyTestGroup.CurrentTestResult is a MyTestResult
where as MyTestGroup is a subclass of TestGroup, and MyTestResult is a subclass of TestResult.

this is good so when Xojo updates the Xojo Unit Testing suite, I just have to drop it in and it works. I am not modifying the original code to extend it.

6

[quote=16095:@Alwyn Bester]
I’ve never attempted this, and never had a need to do so either. Myself and a colleague are just comparing Xojo with other languages, and he posed this question to me, and I wasn’t too sure how to answer him.[/quote]
It helps avoid one of the issues in the “fragile base class” problem
It doesn’t get rid of it entirely though
However IF you want “virtual properties that can be overridden” use a pair of methods using assigns for the setter & then you can override those in subclasses.
Fortunately Xojo makes it easy to change an implementation from an exploded public property to computed property to get/set pair with users of the class never having to change syntax.

7

You can actually override a property: in the code of the subclass’s property you need to cast Self to the superclass type instead of using the Super keyword. But it is not recommended (and therefore not documented) - it is not future safe.

8

If you declared it as a computed property with the same type & name as in the super that doesn’t override it - that shadows it.