Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pitt!willett!ForthNet
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: NEON/Object Oriented Forth/OOF
Message-ID: <2861.UUL1.3#5129@willett.pgh.pa.us>
Date: 8 Jun 91 02:20:47 GMT
Organization: (n.) to be organized.  But that's not important right now.
Lines: 32

Category 3,  Topic 46
Message 109       Fri Jun 07, 1991
G.LEFAVE [Gene]              at 17:08 CDT
 
 
 To: dwp@willett.pgh.pa.us (Doug Philips)
 Subject: Re: OOF


Regarding types:

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.

Gene
-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp