UDTs are what they are, Objects, Classes etc are another...;-)

Phylo: "I guess I don't really know much about it. It all seems so simple to me I don't see the differences. In C++ OOP, you can inherit from multiple classes, in Java, only one. To me that just sounds like C++ has greater control over it, allowing the ability to create the pegasus from bird and horse or just use a modified horse."

I don't think C++ is more versatile because of the multiple inheritance model it supports. All that caounts is to be able to create a Pegasus Object, how it can be done is basically irrelevant. What multiple inheritance has shown in it's history is that it had the ability to create new cans of worms faster than the works could be thrown in the river and all you're left with is a worm infestation. ;-). I can't begin to count the times where I heard someone say something like "well if we didn't use multiple inheritence we would have been done a long time ago." and well in these cases, they were 100% right. with plenty of documented logs that proved their points. As far as BASIC OOP is concerned, this type of detail shouldn't be too relevant per se, not when compared to how to make a BASIC OOP implementation. Ultimately it definitaly shouldn't be the only item on the BASIC OOP list either. It needs to go far beyond all that in order to keep a BASIC flavor at all times.

Phylo: "I personally don't really want OOP, and would recommend no inheritence (and therefore also no function overriding). I typically use C++ when I want program that way, and QBasic when I want a simple flow of program logic. The only thing I would want added in this way is the ability to use arrays in TYPE's (and variable length strings!) and to be able to tie functions to them. If there is a necessity to use naming of one language, I say C++ (only because I know C++ best, though there is also that QB64 is written in C++). I don't really care what names are used, it would be easy to learn whatever it is. Actually, I take that back. I don't want another object-creation,,, template, thing, but if we do have one why not just call it OBJECT?

So, my idea of BASIC OOP is using TYPEs, which can have variable length strings, arrays, and functions(/subs), in an OOP sort of way."

You can't have OOP without Inheritance. Inheritance is one of the founding pillars of OOP. Just like encapsulation and polymorphism (Later can the 4th pillar called Abstraction). If you don't want inheritance you don't want OOP you just want an extended TYPE that can handle arrays and functions/subs in it's definition. This can't be compared to OOP because this would never play an OOP role. It would just be used to organize and manage a set of variables and functionality that would make use of those variables.

Phylo: "There is one issue I have in C++ when using OOP, which would be nice to be able to do a better way (if there is one) (this only matters if inheritance is added). Here's the generic version, after which I'll provide one of my examples:
I have an abstract object type A, from which x objects (Aa, Ab, Ac...) are derived. I have an array of these objects (A), using the abstract type because each one could be any one of the derived types. I now need to call a function of one of the objects in the array, but only if it is of a certain type, which cannot be known because I only know of the properties defined in A.


Let's say I have this (QBasic style):
{
TYPE DBOXITEM
END TYPE
TYPE BUTTON _ISA DBOXITEM
shortcutkey AS STRING * 1 'Activates the button
END TYPE
TYPE EDITBOX _ISA DBOXITEM
END TYPE

TYPE DIALOGBOX
items(10) AS DBOXITEM
END TYPE

DIM Popup AS DIALOGBOX
DIM eb AS EDITBOX
DIM but AS BUTTON
Popup.items(0) = eb
Popup.items(1) = but

keypress$ = INKEY$
FOR i = 0 TO UBOUND(Popup.items)
IF keypress$ = Popup.items(i).shortcutkey$ THEN
'Activate button
END IF
NEXT i
}

My problem is that this will bomb out (if it even manages to compile) when I press a key because it will try to get the shortcut key for eb, which doesn't have one. There are only two solutions I can think of. One, give every derived type a shortcut key that has some value representing no shortcut. This defeats the point of deriving the objects because the base object will have to have all the properties of all the smaller ones. Two, give the base object a variable that specifies the type, which seems to me a very messy way of doing things."

You could simple add a ControlType your definition that could help you out here. and your of would become something like

IF Popup.Items(1).ItemType = BUTTON THEN
...IF keypress$ = Popup.items(i).shortcutkey$ THEN
...'Activate button
...END IF
END IF

But yes, that's beside the point in this discussion ;-).

Any ideas on a (BASIC) way of doing it? Perhaps two ISA uses.
_ISA Statement - Defines the new TYPE as a derivative of the specified type.
_ISA Function - (any variable v, any type t) returns true if v is of type or a super-type of t. "

This could be a good idea but it's not something I would force in the implementation of the BASIC OOP. I like to consider this (the _ISA function that is) as a loss of control statement. But as long as you have the control, you shouldn't need this kind of trick. Basically every object you create from any derived type knows what it is so instead of trying to find out from outside the object you would just give the objects the ability to identify themselves and this that would eliminate the need for a conditions. In a BASIC OOP would could push that notion several folds forward but i'm not going to get in the details of this here. Look for a post from in the very near future to really clearly explain what I mean.

PhyloGenesis