Virtual dispatch for computed properties

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.