Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!liuida!mip
From: mip@IDA.LiU.SE (Mikael Patel)
Newsgroups: comp.lang.forth
Subject: Re: Object oriented programming extension for forth.
Message-ID: <1990Aug24.133045.12494@ida.liu.se>
Date: 24 Aug 90 13:30:45 GMT
References: <1602.UUL1.3#5129@willett.pgh.pa.us>
Sender: news@ida.liu.se (News Subsystem)
Organization: CIS Dept, Univ of Linkoping, Sweden
Lines: 66

In article <1602.UUL1.3#5129@willett.pgh.pa.us> dwp@willett.pgh.pa.us (Doug Philips) writes:

>    Why do you want to put OOP into Forth?  What do you think it
>    will get for you that you don't already have?
>
>Part of my answer is that I want to gain the reusability and encapsulation,
>etc. from OOP and still have the nice Forth development environment.  Just
>as C++ lets you link with C code and lets you gradually convert old
>applications to OO style, so this would let you add OOP to existing Forth
>code.  You might even mix OOF with some kind of Forth Expert Systems
>extensions and with regular Forth code.  Despite, or perhaps especially
>because of, that I do not want to invalidate the OOP perspective in the
>process of providing it.  What would be the point?

There exist a number of well established paradigms for programming 
today; functional, procedural, process, rule-based, logic, object-
oriented, and so on. Restricting oneself to programming in only one
paradigm is a mistake. All are valid, fruitful, and allow problems to
be solved quicker in their specific domain. Allowing object-orientation 
in forth is much like opening the door to concurrent programming. 
Being able to mix paradigms in the same language is a strength and 
not a weakness.

Forth has this wonderful nature of acting as a meta language and allow
all of these paradigm if they are needed. A common OOP extension will
allow use to reduce the otherwise very large name space in forth and
write reusable code. Who wants to have to rewrite lists, sets, etc?
It is the 90's not 70's.

>One of the reasons I started to complain about OOF extensions now was it
>*seemed* like a lot of people were putting non-trivial work into them.  I
>don't/didn't want to see all that effort go into implementing what I
>perceive to be an inferior solution.  I was hoping that I could convince
>some of the people now doing OOF's to refocus their goal before the
>threshold of "I've put too much into into it to change now" was reached.  I
>now think I failed.  I realize now that by the time any of that work was
>announced a lot of effort had gone into it.  I suspect enough effort to
>push it over the threshold.  I still hope otherwise, esp. since many OOF's
>are less than 6 or so screens.  It really depends on how much code has been
>developed that uses those OOF extensions.

I have seen a number of OOF implementation that have not impressed me.
As Mitch points out everyone has one. But to be able to take the next
step we must agree on a 'standard'. That is of the reasons these 
discussions are needed and valuable. If everyone has their own idea 
about OOF we will never be able to get up to the C++ or Smalltalk-80 
level and never ever to the system level of Smalltalk. And I don't
want to be negative!

Using forth gives us the advantage, compared to other language-addicts,
that we don't have to write a pile of code to get something done. To
demonstrate a concept etc. 6 screens (2-3 pages) is about the size of
most (any!) extensions to forth :-)

What is your suggestion? How should be go about attaching this problem?
I think that if more forth users and OOF implementors present and 
discuss their solutions we should be able to agree on a word set for
OOF.

We do need it! That's out of the question. But how?


>-Doug
>

-Mikael