Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!touch!mikeh
From: mikeh@touch.touch.com (Mike Haas)
Newsgroups: comp.lang.forth
Subject: Re: Object Oriented Programming ?
Message-ID: <217@touch.touch.com>
Date: 25 May 91 01:57:10 GMT
References: <1991May22.134354.11444@mlb.semi.harris.com> <1991May23.085940@Unify.com>
Organization: Touch Communications
Lines: 80

>bie@solman.mlb.semi.harris.com (Ben Eaton) writes:
>> 
>> 
>>         I know I am going to get flamed for asking this but I am going to 
>>      ask it any way.
>> 
>>           QUESTION -        What is "Object Oriented Programming"?
>> 
>>         Maybe I just fell off the turnip truck (that mite explain the 
>>      bruises).  I keep running across this term but I have yet to see an 
>>      explanation or a definition of it.
>> 
>>         If someone out there could dispel my ignorance (well at least some 
>>      of it) I would be very grateful.
>> 
>>      Thank you,

I can give you some example statements of object-oriented code to
see how coding style changes with OOP.  This works with ODE (Object
Development Environment), an extension to JForth on the Amiga, and comes
with the jforth package.  I think there's also a version of ODE that will
run on Mach2 on the mac, but don't quote me.

OOP allows you to define data objects like forth, but when tyou do so
in OOP, you automatically inherit some set of functions that 'know' about
that object. 

Consider an ARRAY defined by forth (FARRAY) and an ARRAY data element
created with ODE (OARRAY).

Both would create something in the dictionary.  with the CREATE DOES> word
of the forth type, one function, the DOES> component is defined to 'know'
something special about the data area.  (the DOES> part of ARRAY calculates
the address of the element based on a CELL's width, for example).

In ODE, an ARRAY definition inherits many functions that know about it's
data's structure.  This is because the ARRAY data type is not created
as a naked new data element, it is a 'child' of a parent data type.
For example, the ODE ARRAY class may be a child of the CELL class (CELL
might create single-element structures, it follows next to create a class
that would 'borrow' from this in creating MULTI-element data storage
of the same cellular size).

In forth, the RUN-time action of FARRAY is only to return the address
of a particular element as in   12 FARRAY  ( -- address )

In ODE, this could be done with a statement like  12 ADDRESS-OF: OARRAY
which would also return ( -- address ).

The power comes into play because you can also have a PRINT: function (they're
called METHODS in ODE) that is smart enough to display the whole data area
in nice formatted dump fashion.  PRINT: OARRAY would produce

  0 =    0
  1 =    0
  2 =  1c0
  3 = ffff
  ok

while PRINT: on a CELL child would print only it's value (not even an index).
You can have many, many functions for each class, and even though they
have the same name (PRINT: OARRAY and PRINT: whatever) they never get
mixed up.  the right thing happens.

Think about this...how bout an array of pointers to ODE OBJECTS.  Assuming
we are storing them in our standard FARRAY, and it was 4 cells long...

     4 0
     DO
        i FARRAY (a)  ( fetch - my reader won't accept the right character )
                      ( -- addr-of-ODE-object )
        PRINT: []
     LOOP             ( the [] operator causes PRINT: to work on )
                      ( whatever is on the stack )

The result could be four different kinds of printouts, based on whatever
type of ODE object was stored in the ARRAY.

This only scratches the surface of OOP, I hope it at least makes enough
sense that your interest is increased, and not the other way around.