Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!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: NEON/Object Oriented Forth/OOF
Message-ID: <2867.UUL1.3#5129@willett.pgh.pa.us>
Date: 9 Jun 91 18:49:28 GMT
References: <2861.UUL1.3#5129@willett.pgh.pa.us>
Organization: (n.) to be organized.  But that's not important right now.
Lines: 28

In article <2861.UUL1.3#5129@willett.pgh.pa.us>,
	G.LEFAVE [Gene] writes:

> I've implemented Dick Pountains wordst in polyFORTH, and used it for a couple
> of months.  The implementation esentially maintains a separate vocabularly for
> each class.  Referencing the name of an object, at either compile time or run
> time, gives you access to the wordset.  How this differs from a "type" escapes
> me.  I regularly use database objects that have numeric, string, dates, time,
> dollars and key types.  All of which share identically named methods.  So far
> I have never needed to know the "type" of an object as it knows its own type. 
> Certainly, if one wanted to, a method named "type" could be added which
> returned the name of an object type.  It seems to me that this runs counter to
> the object philosophy, namely that a program shouldn't know about the
> implementation details of the objects.
> 
> Perhaps you could describe how a "type" is different from the list of methods
> that are provided by a class.

There is no difference.  Forth is not traditionally a typed system.
OOPs are.  Not that the programmer/user has to be aware of the types,
bu the system itself does.  I'm not a long time Forth user, but every
NON-OOF Forth I've seen did nothing to tell you if you should use
+ or D+ or F+ ... the programmer has/had to make that decision.  In
OOPs, you just use + and the system figures it out for you.

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