So what the heck is Norm on about NOW ?
Properties. Specifically computed properties.
Normally you dont want to be shadowing properties and if you do you need to be careful about how you do it so it doesn’t muck up everything. But even when you DO shadow “right” there can still be issues.
And the reason this comes up is because the DECLARED type of an item may be REALLY relevant.
For instance if you have
Class Item property Foo as Integer End Class Class subItem Inherits Item Computed Property Foo as integer Get as Integer break return Item(self).Foo End Get Set(value as integer) break Item(self).Foo = value End Set End Computed Property End Class
This can lead to a messy situation.
If you try something like
Dim c As Item c = New Item c.foo = 129 // sets Foo directly and never hits a breakpoint in the computed c = New Subitem c.foo = 9
You will not get ANY complaints from the compiler
The local we declared, c, can hold a reference to an Item OR any of its subclasses – since any of its subclasses IS also the super type (thats how inheritance works)
But with properties the DECLARED type matters. Although the debugger knows that, at the end c holds a reference to one of the SubTypes, the PROPERTIES that are accessed are those of the SUPER class in this case (actually what would be correct to say is the properties of the declared type)
And so, because despite a computed property being a lot like a pair of methods, its not treated the same. For instance, if the code above is altered to
Class Item Public Sub Foo() as Integer break return privateFoo End Sub Public Sub Foo(assigns v as Integer) Break privateFoo = v End Sub Private property privateFoo as integer End Class Class subItem Inherits Item Public Sub Foo() as Integer break return super.Foo End Sub Public Sub Foo(assigns v as Integer) Break super.Foo = v End Sub End Class
with the same code trying to set and get the value
Dim c As Item c = New Item c.foo = 129 // sets Foo directly and never hits a breakpoint in the computed c = New SubItem c.foo = 9
You’ll see a vast different. This time the RUNTIME type matters and the code in the subclass methods DOES get called.
This is because methods, unlike properties, do use dynamic or virtual dispatch (the names get used interchangeably quite frequently) But properties do NOT. so whatever declared type a local or parameter is matters as to which property you might actually be accessing.
Sometimes this is where you need to cast (which kind of breaks the whole idea of using OO anyways since now you end up with big select case statements to handle many supers & subclasses)
IF subclasses computed properties could be handled using the same dynamic dispatch mechanism that methods use it would make it possible to put properties in the inspector behaviour AND have subclass properties overload the super class ones.
Right now you have to pick between one or the other since computed properties can be in the Inspector Behaviour but arent virtual, or you use method pairs which ARE virtual but cant be exposed in the Inspector Behaviour.
Its crummy to have to make this choice at all.