Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!decwrl!purdue!haven!uvaarpa!hudson!vivaldi.acc.Virginia.EDU!pmy
From: pmy@vivaldi.acc.Virginia.EDU (Pete Yadlowsky)
Newsgroups: comp.lang.forth
Subject: Re: objective forth
Message-ID: <1847@hudson.acc.virginia.edu>
Date: 4 Aug 89 20:02:17 GMT
References: <0Yn-Vly00WBn01=20j@andrew.cmu.edu> <10451@dasys1.UUCP>
Sender: news@hudson.acc.virginia.edu
Reply-To: pmy@vivaldi.acc.Virginia.EDU (Pete Yadlowsky)
Organization: University of Virginia, Charlottesville
Lines: 46

In article <10451@dasys1.UUCP> aj-mberg@dasys1.UUCP (Micha Berger) writes:
>I don't understand how a weakly typed language like FORTH can be fit into the
>object-oriented mold.

I'm not sure I see a necessary connection between strong typing and
OOP. Anyway, Forth, with its extensible compiler and innate abstraction
fits quite well with OOP. JForth's ODE is an excellent example.
Where do you see the problems?

>Nor am I sure why anyone would want to.

Well, for the same reasons one would use OOP models to approach a problem
in any language...data/process abstraction, instancing, inheritance, etc.

>I don't understand the idea of adding an extra abstraction unles it:
>	1- fits the intuitive description of the problem
>	2-   "   "     "           "      "   "    "

Yes and yes!

>        3- speeds up execution time

Probably not, but it sure as hell speeds up development time.

>        4- reduces required memory space

Depends.

>Objects just present simething else to learn.

So did Forth. Remember?

>FORTH already has most of the
>advantages of OOP if you make good use of VOCABULARYs.

No, not even close. Vocabularies, though useful, are not even
a crude approximation to OOP.

>This doesn't really belong in a FORTH group,

Sure it does. Why not?

Peter M. Yadlowsky		| "Pay no attention to that man
Academic Computing Center	|	behind the curtain!"
University of Virginia		|
pmy@Virginia.EDU		|