@Andrew L That's what I'm saying. The virtual method
Window1.Bar is being dynamically dispatched based on the runtime type of Self/Window1, not the
c parameter. But it's not wrong, it's single dispatch polymorphism.
actually its decided at compile time and which to dispatch to is NOT determined at runtime in any way
@ChristianSchmitz I think it is fine and you as developer should use methods and overwrite them or do isa check yourself.
which leads to fragile code as everytime you add a new subclass IF you have code that is stylistically like this then you have to make sure you add a new "select case" or "ISA" check for every new one you add
and THAT is why I see this as a problem
can it be designed around ?
many times yes
but not always
and therein lies the problem
Sub bar(extends c as class1)
Sub bar(extends c as CustomClass1)
dim c as Class1
c= new CustomSubclass
// have to do the check in this order because a CustomClass1 is also a Class1
// but a Class1 instance is JUST a Class1 instance
if c isa CustomClass1 then
msgbox "c isa CustomClass1"
elseif c isa Class1 then
msgbox "c isa Class1"
c.bar // <<<<<<< this one might surprise you as to which one gets called !
again we have much the same issue
and IF you extend a built in class you dont have always have the same options to deal with this like you might if it was your own code