David wrote:
> Ok.  Here's the simplest one I can think of.  Let's say you have a class 
> defined for cShape like so:

Okay, let's see if I understand this so far.  A "class" is similar to
what we all know as a "data type," but in addition to that it might also
have "methods" (which we usually call "functions" and "procedures")
associated with that class.  And in addition to that, a given class can
be defined as a "subclass" of some other class.  And what that means is:
if a given object (call it "myObject") is a member of class "A", and
class "A" is a subclass of class "B", then myObject is also considered
to be a member of class "B".  Am I right so far?

I guess we already have something similar to "subclassing," in a limited
sense, but we don't call it that.  For example, you could say that short
integers are a "subclass" of long integers; that is, any variable or
expression that counts as a short integer could also count as a long
integer (though the reverse isn't true).  Likewise, you could say that
long integers are a subclass of double-precision reals.  These
"subclasses" are fixed, and built into the language, whereas OOP allows
you to make up your own subclass relationships.

An "instance" of a "class" is roughly equivalent to what we'd call a
"variable" of a given "type".  The words "instance" and "object" are, as
far as I can tell, more or less interchangeable.

> 
> BEGIN CLASS "cShape", ""
>   DIM oRect AS Rect
> END CLASS
> 
> METHOD Draw
>   FrameRect(self.oRect)
> END METHOD

This syntax confuses me a bit.  From the remainder of your message, it
looks like you're intending this definition of "Draw" to be associated
with the "cShape" class.  In that case I'd have expected something like
this:

  BEGIN CLASS "cShape", ""
    DIM oRect AS Rect
    METHOD Draw
      FrameRect(self.oRect)
    END METHOD
  END CLASS

> To create a new object of this class:
> 
> myShape = NEWOBJECT(cShape)

Sounds similar in concept to DIM'ing a variable as a certain type. 
However, I would guess that, unlike DIM, NEWOBJECT probably also
allocates a block on the heap to hold the object's data.

> To set the rect and tell your object to draw:
> 
> 'direct manipulation of a property
> SetRect(myShape.oRect,10,10,100,100) 
> myShape.Draw

Okay...Looks like "myShape.Draw" means "Apply the method 'Draw' to the
object 'myShape'.  If there's more than one version of the 'Draw' method
in the world, then use the one that's most closely associated with the
class that 'myShape' belongs to."  In "non-OOP" terminology, we'd do the
analogous thing somewhat as follows:
  FN Draw(myShape)
_except_ for the fact that OOP allows different versions of "Draw" to
exist, while the "old-fashioned" way allows only one version.

> Now suppose that you want to also have objects that do ovals as well.  
> Rather than changing your cShape code which is already bug tested, and 
> working fine as it is, you create a subclass of cShape, and override the 
> Draw method, like so:
> 
> BEGIN CLASS "cOval","cShape"
> END CLASS
> 
> Since cShape already has a rect, there is no need to DIM one in the 
> subclass.
> 
> METHOD Draw         'override
>   FrameOval(self.oRect)
> END METHOD

Again, I would have expected this to look like:

  BEGIN CLASS "cOval", "cShape"
    METHOD Draw        'override
      FrameOval(self.oRect)
    END METHOD
  END CLASS

...so that (this version of) "Draw" would be explicitly associated with
the "cOval" class.

So then, if I create a "cOval" object...
   myOval = NEWOBJECT(cOval)
...then, as I understand it, myOval _automatically_ gets an "oRect" data
field associated with it, on account of the fact that "cOval" was
defined as a subclass of "cShape".  myOval _inherited_ that oRect
property from the "cShape" superclass.

myOval is now a "cOval", but it's also a "cShape" (just as 1623 is a
"short integer," but it's also a "long integer").

And, if I hadn't stuck that new definition of "Draw" into the "cOval"
class, then myOval would _also_ have inherited the "Draw" method
contained in the "cShape" definition.  But by sticking that alternate
"Draw" in there, I'm "overriding" the other "Draw".  So that means:

* Anything that's a "cOval" will use the "FrameOval" version of Draw.
* Anything that's a "cShape" (but not a "cOval") will use the
"FrameRect" version of Draw.

And, I suppose, you could have still another "Draw" method that's
associated with objects that are not "cShapes" at all.  For example, you
might have a completely separate class called "cBitmapPict," and have a
unique "Draw" method associated with that class.

Okay, if I'm on track here, I can start to see where OOP _might_ come in
handy for some things.  :-)

- Rick