Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!dsl.pitt.edu!pitt!willett!dwp From: dwp@willett.pgh.pa.us (Doug Philips) Newsgroups: comp.lang.forth Subject: Re: Object oriented programming extension for forth. Message-ID: <1602.UUL1.3#5129@willett.pgh.pa.us> Date: 24 Aug 90 05:06:05 GMT Organization: String, Scotch tape, and Paperclips. (in Pgh, PA) Lines: 105 In <1990Aug23.160723.437@ida.liu.se>, mip@IDA.LiU.SE (Mikael Patel) writes: > The issue is how to apply messages. If we look at it from the syntax > level point of view we have to handle the parameters, the object, and > the message. Using an active message style (function) would look like > this: > > "10 10 aPoint moveTo" > If the message is passive a prefix message-passing function could be > used: > SEND > "10 10 aPoint SEND moveTo" > Or even prefixing the object: > SENDTO > "10 10 moveTo SENDTO aPoint" Or even postfix: SEND > I believe the first style to be the "natural" choice and it blends nicely > with forth. This is what I have trouble with. It is the same as advocating the principle of least astonishment. What will or won't astonish, or what will or won't seem natural is in the eye of the beholder. One of the points of doing OOP is to use the OO paradigm. That means that your old habits and ideas about "naturalness" are not going to be correct in the OO world. OOP means looking at program methodology in a different way. If you are going to bend OOP into indirect-functional-call-Forth I doubt that you will attain the new perspective. The question I should have asked is: 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? > Implementing a OOP extension will have to be a hybrid solution much > like C++, Simula, and Turbo Pascal 5.0. Data will be divided into > the groups objects, and primitive data types such as integers, float, > etc. This is independant of syntax, since Forth is so totally free with letting you roll your own. I agree that making all primitive types into objects is going overboard for Forth. At that point you're probably better of hacking a SmallTalk implementation to make the syntax post-fix. > We also have to decide if classes > should be objects. In this case we will need meta-classes. Most > hybrid languages such as the ones above view the class and a language > construct, not an object, and a large amount of the class information > is lost at compile-time. In forth we can take some advantage of > this information (instance-variable schema, super class pointer etc). You may only need one meta-class (Isn't that what XLisp does? Its been too long, I can't remember). Depends on how sophisticated you want to get. Maybe we could even have a layered approach. Words that you can use if you have the "classes as objects" extensions loaded. I wonder how the factoring for that would work out... > What I am looking for (thinking about, and designing) is an extension > that is not bound to an implementation. More a specification of > an interface. So far I have designed and experimented with three basic > models of OOP in forth; relations, prototypes (or also called slot based), > and the class-instance model. These are all available in the next > release. I'm just doing some more testing (gamma-testing) and making > some more examples. 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. > We havn't come to the real hard decisions yet. Garbage Collection. > Persistence. Multiple inheritance. And of cause, a class hierarchy for > abstract data types; sets, tuples, mappings, and sequences. I suspect that looking at the latest C++ (2.0, 2.1, 2.X?) might be informative. Those people have thought hard about those issues. C/C++ is not Forth, I know that. But they share many of the same goals, and many of the same restrictions. -Doug --- Preferred: ( dwp@willett.pgh.pa.us OR ...!{sei,pitt}!willett!dwp ) Daily: ...!{uunet,nfsun}!willett!dwp [last resort: dwp@vega.fac.cs.cmu.edu] --- Preferred: ( dwp@willett.pgh.pa.us OR ...!{sei,pitt}!willett!dwp ) Daily: ...!{uunet,nfsun}!willett!dwp [last resort: dwp@vega.fac.cs.cmu.edu]