Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pitt!willett!dwp
From: dwp@willett.pgh.pa.us (Doug Philips)
Newsgroups: comp.lang.forth
Subject: Re: OOF
Message-ID: <2855.UUL1.3#5129@willett.pgh.pa.us>
Date: 4 Jun 91 17:15:03 GMT
Organization: (n.) to be organized.  But that's not important right now.
Lines: 64

In article <9106020320.AA27050@ucbvax.Berkeley.EDU>,
	UNBCIC@BRFAPESP.BITNET writes:

+Good point. But that's not part of the OOS, it's just an way of handling
+things. I *really* prefer named objects, i.e., Objects would return already
+known objects, instead of creating new ones.

Well, not necessarily.  Naming objects is not exactly the same as already
known objects.  Must the objects in an array have names?  Must the objects
in a list have names?  If you have an OOF with "active" object names, then
those have to be special cases... Very Inelegant.

+Knowing types? No. OOP requires that only methods defined for an object have
+access to it's data fields. I handle this with vocabularies. A class is a
+vocabulary. It's methods data fields are defined inside this class, so only
+this methods can have access to the fields (Of course one could get-order, but
+it doesn't matter). The fields are allocated with a special word, like ARRAY.
+No types. What then happens?
[Example elided... -DWP]
+                                 No types. It's just a complex DEFERred word.

Sigh.  I should have KNOWN that would cause problems.  OOP requires objects
to have a type.  Forth is traditionally untyped.  The stack is just a stack
of numbers.  Forth traditionally requires the programmer to know which of
+ D+ F+ .. to use.  In order to take that requirement away from the programmer,
the objects on the stack must have a type associated with them (how that
association is achieved is an implementation detail).

+=> OOP usually requires automatic memory management.
+=>      Forth is traditionally very flexible in letting you roll
+=>          your own memory management.

+Automatic doesn't mean you can roll your owm memory management. In fact, if you
+don't want one of the kinds I offer to you (static, dynamic and virtual), you
+can do your own without changing anything else.

I was attempting to show that you would have to add those kinds of memory
management to Forth, in addition to adding your new defining words.

+=> Therefore adding OOP to Forth is _not_ just adding a few new defining
+=> words (object, class, message, whatever), but requires an integrated

+Right.

+=> effort to achieve a typed _and_ memory managed system onto which an OOP
+=> can be added.  That is, if you want to go the whole nine yards and have

+Wrong. The memory management system can be yours. And you don't need types.
+Inheritance, hidden data fields and everything else can be obtained by just
+another level between you and the machine. ALLOT won't just ALLOT, it will keep
+the size and the offset of this. Things like that.

I seem to have hit a magic button with my use of the word 'type'.  If you don't
have types you can't tell the class of an object, and therefore cannot
do method lookup for that object.  As for memory management... I suppose the
key issue not some particular implementation, but the interface used by the
OOP system.

+Daniel C. Sobral
+UNBCIC@BRFAPESP.BITNET

-Doug
---
Preferred:  dwp@willett.pgh.pa.us	Ok:  {pitt,sei,uunet}!willett!dwp