Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!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: <2868.UUL1.3#5129@willett.pgh.pa.us>
Date: 9 Jun 91 19:16:46 GMT
References: <9106070453.AA08025@ucbvax.Berkeley.EDU>
Organization: (n.) to be organized.  But that's not important right now.
Lines: 85

In article <9106070453.AA08025@ucbvax.Berkeley.EDU>, 
	UNBCIC@BRFAPESP.BITNET writes:

>An array of objects. The array have name, right? That's ok. The whole problem
>is that, in Smalltalk for example, when an object do something (2+2, for
>example), it generates an object, allocating memory, creating links and lot's
>of stuff. I think that Forth will *NEVER* be completly OO. So, the result of
>operations, such as 2+2, will not be an object. Smalltalk will create an object
>4, wich will be destroyed later, when it's not needed anymore. That's what I
>call a nameless object.

The array may not necessarily have a name, but it could.  Do all your
data types have to have names to be instantiated?  What if the only
place you use arrays is, for example, as elements of a list?  Must you
name them then?  What about the nodes of a tree, do they all have to
have names too?  As for SmallTalk's "2+2", yes it makes a new object
"4", but then Smalltalk treats small integers specially so that all
the nonsense of creating memory and links and such doesn't happen.  As
for things that are created and destroyed later... In SmallTalk the
most heavily allocated and freed objects are contexts (sort of like
procedure call frames or closures).

>TYPE, from what I've learned, it's the description of a data structure. A typed
>language treats diferent types in diferent ways. A strongly typed language
>assures an exact mach of types. But, in OO, you *HIDE* the structure. What you
>put in the stack is an address to a record with a list of methods and data
>space. (Well, it's usually more complex, but can be reduced to that). I just
>can't see a type here! There is NO description of the data structure, just the
>CFAs of methods that handle the object. There is no analysis, by the compiler,
>or run-time, of ANYTHING. There is a search in the list of methods, and the
>execution of a CFA. If you consider the list of methods a kind of type, ok. But
>I consider this an object.

Whether or not strongly typed languages implement operations on
different types in different ways, they often let the programmer
_write_ the operations the same.  Forth and assembly languages are the
only languages I know where you have lexically different operators for
addition depending on the types of the operands.

As for your view of type as a description of a data structure, I think
you are being overly myopic.  Whether the analysis is done at run time
or at compile time is merely an implementation detail.  Some languages
let the programmer decide (i.e. C++).  As to what I consider a type...
What do you consider an integer to be?  Just <n> bytes of memory?
What about the allowable set of operations ( + - * / ... )?  Which
characterizes the type more?  I would say that both are important.  I
consider an object an instance of a type.  Whether or not that
consists of a list of methods depends solely on the implementation.
Presumably an object may also have some object specific piece of memory
allocated to it too.

>+-.... Looks like what you don't like is having overloaded operators... I think
>of overloaded messages as a vectored word. For me, it's like writing KEY and
>knowing that in another place in my program I decided what KEY means. For
>example: SERIAL KEY (object message) and KEYBOARD KEY. Maybe SERIAL is an
>object with a pointer to the KEY that will be used. Maybe SERIAL is a word that
>assigns a new CFA to KEY.

I haven't the foggiest what you are talking about here.  I said
nothing about overloaded operators.  You claimed that all you needed
for an object was a pointer to a list of methods.  My claim was that
you have just introduced a type mechanism.  (That is not the only way
to do so though).

>One more thing, remember that an object don't need to have data space. How can
>you call something that DON'T HAVE any datum a typed thing?

Because it is not the data space which distinguishes types, it is the
operations that distinguish types.   How many different types can have
objects with a data space of 4 bytes?   Depending on the size of a
byte and other machine specific things, you often have:  Some kind of
integer type, some kind of floating point type, an array of four
bytes, an array of two 2-byte quantities, and array of one 4-byte
quantity, a pointer, an offset and a length (two bytes each).... and
on and on and on.... What makes those types different?  It is
certainly not the amount of data space allocated to them.  It is the
way in which that space is interpreted.  I.e. what messages it
understands and what those messages "mean."

And that holds for objects that have no data space (i.e. stateless
objects, pure functions, etc.)

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