Hi,

Does anyone actually use OO in forth these days?

If so, do you: (1) have your own OO implementation, or (2) use someone
else's?

I'm at a fork in the road with the multiplatform C-based Forth I'm
developing. I've built an OO framework - dynamic prototype-based - as an
optional add-on, which can be easily compiled in or out, or dynamically
loaded at run time.

The dilemma is whether to build a big fat 'Forth Foundation Classes'
layer using it, or whether to implement all the extras with a classical
Forth feel, but adding an OO shim on top.

Do you feel OO has a place in forth, or do you feel it's a wasteful hack
which artificially pushes the ideas of other programming paradigms into
Forth, and that anything done with OO would be better done with
traditional Forth and smarter factoring?

(I'm writing as someone who has spent years writing in Python, and is
getting back to some Forth programming after 5 years away from it).

Cheers
Dave

DavidM wrote:

DavidM wrote:

It has been decided that there should be no standard OO for Forth. It
is felt that it is best that you do either 1) or 2), or you could buy a
Forth that has its own proprietary OO system. Try Googling for "OOP
Forth" or whatever. Have fun sorting it out and Good Luck.

-Doug

DavidM wrote:

Doug Hoffman wrote:

The basis for this decision is that no OO extension to Forth is really
in "widespread use". Systems like Win32Forth, SwiftForth, or
Gforth/bigFORTH come with OOP extensions, but each of them is different,
and the authors have reasons for that (different reasons, for sure). So the
key to get to a standard OO is first to make one of these extensions be
used by several systems. And an OO extension isn't just used because it's
there (e.g. bigFORTH's OOP extension is available in an ANS Forth
compatible form), but because there's something you gain by using it.

Therefore (not only, but that's part of the reasoning) I'm currently porting
MINOS over to VFX.

Bernd Paysan wrote:

Of course you're right. A system that has only been used for 24+ years
in four different Forths on two OSs (Windows and Macintosh) with an ANS
compatible version available since 1996 is surely not yet ready for
general use.

DavidM nowhere.com> wrote:

Yes. They use a variety of OO systems in Forth.

Who are your intended users? Which approach would be easier for you? If
you build a big fat FFC layer, do you have to document it all? Would
your users tend to get lost in that documentation? On the other hand,
would your prospective users demand such a thing?

Since your prospective users will probably prefer to change their habits
as little as possible, you should notice what they're doing already.

On Mon, 21 Jul 2008 07:40:45 -0400, Doug Hoffman wrote:

If you mean the Neon-style stuff, since 1998 according to the
change notes.

We supply three different OOP flavours (soon to be four). We don't
like having that many, but the customer (or wallet) is always right!

OOP models are not there for themselves, but as tools for larger
requirements. Those larger requirements have lead to a range of
OOP tools. As Elisabeth has pointed out, very few people in the
embedded application space require OOP.

We tried to standardise OOP, but it was an effort that nobody was
prepared to champion and write a proposal for. My current opinion is
that the Neon model has the greatest traction at the moment, but that
OOP systems should be libraries for the moment. Unfortunately the
Forth200x system has no library model.

Stephen Pelc wrote:

Thanks for the information. Yes. I meant the Neon-style stuff.

I forgot to add that this same Neon-style OO system successfully
controlled the telescopes at the Yerkes National Observatory in Chicago
for many years. It also processed complex color images from the scopes.

Of course. I keep forgetting to preface my posts with **Does Not Apply
to Embedded Forth**

On Mon, 21 Jul 2008 09:13:35 -0400, Doug Hoffman wrote:

IMHO complex extensions require a reference implementation with
a few portability harnesses before they can be standardised. I
don't see this a much different from the position in any other
language.

The Neon model has traction *because* a portable implementation
was published. Standards mostly follow common practice. Common
practice is greatly helped by reference implementations. In
turn, reference implementations are made more useful if someone
champions them. Dome well enough, the reference implementation
becomes the standard.