I kinda like the 2nd example ;-)....But yeah...

I think there might be something to learn about the OOP implementations of ObjectPascal, Ada, Python, PHP and any other language that supports OOP because they were implemented different ways for the main reason of keeping OOP true to the language and OOP's definition. IE using OOP in PHP or python is made to feel like any other code you'd do in those languages (same for ada, C++ ObjectPascal etc).

A BASIC OOP should follow that as well. Since BASIC is what it is, this can probably extend to follow some or all of the following.

1. Be as simple as possible (syntax wise) IE as quick to learn as possible too
2. Be as forgiving as possible forgiving as in freestyle
3. Assume as many things as possible (be it defaulted values or defaulted methods or other types of assumptions) but allow to assume nothing (if programmers what to have complete control over everything in his/her object hierarchy). Which keeps it short, quick and simple.

I say assume (default and/or omit) because of the definition of OOP. For example if I have the following (I'm omitting the _ but we can imagine where they go ;) ):

CLASS Shape
..... SUB Draw(X AS INTEGER, Y AS INTEGER< Foreground AS INTEGER, Background AS INTEGER)
END CLASS

INTERFACE World
X AS INTEGER
Y AS INTEGER
Z AS INTEGER
Height AS INTEGER
Width AS INTEGER
Depth AS INTEGER
Initialize
Draw(X, Y)
END INTERFACE

And I derive a circle class

CLASS Circle EXTENDS Shape
END CLASS

CLASS OtherSHape INHERITS Shape
END CLASS

CLASS Environment IMPLEMENTS World
END CLASS

Circle has a Draw Method but since Circle Extends Shape, this method can be assumed as overridden

OtherShape just inherits Shape so it gets all its methods (and properties) but doesn't extend it. At this point it could be overwrridden if needed

Environment is an interface and therefor is forced to implement the methods of it's parent object (World in this case). This interface type class is useful when dealing with large sets of similar objects.

This is somewhat borrowed from VB (but not 100% verbatim) but the inner workings would change to do a lot of assumptions that can be safely done unless the programmers wants to specify everything him or her self. But this kind of syntax, because of the different way to derive the object from other objects which gives it certain conditions would allow to do a lot more assumptions and defaults to keep the coding to a minimum when defining objects (much like the assumption that everything is public unless specified otherwise.

We could even push that further and let the compiler analyze things and only have one way to derive objects and let the compiler determine if there's overridden methods or not. However, the good thing about interfaces is that they are static definitions and therefore if an object implements an interface everything can be assumed about that object.

But this is just for the sake of discussion at this point, everything can change, but I do like this idea I think it gives the users options and these options can make their object hierarchies safer, give them more control while keeping the syntax to a minimum (and therefore the complexity to a minimum. So although I don't expect this to be copied verbatim when OOP is done in QB64, maybe there's some cool stuff to learn from this concept (among other things) to make a better BASIC OOP ;-).

Just a thought (ok just a couple thoughts lol). But yeah, everything is open for discussions.