Re: OO syntax

Andrew Haley wrote:
You'd be inserting a fairly complex Lua-like layer between whatever
object model you use and the Forth below, which I don't think would be
easier or faster than writing an OO extension in standard Forth.

Every time the subject of object orientation comes up in comp.lang.forth, there is a predictable pattern. You have a few people who are proud of their OO implementations giving good reasons why their particular model should be adopted as a standard. It's entertaining and sometimes you learn something new from it, but most of the time, it's nothing that hasn't been said dozens of times before.

Then you'll have the discussions that focus on syntax variations, early/late binding decisions, access restriction, and other quasi-substantial issues.

And then-- because this is comp.lang.forth-- the inevitable discussions that center around insane premature microoptimization of things like polymorphic method dispatch will start. (You know you've entered software la-la-land when people can accurately quote the number of processor cycles and memory accesses a technique takes, but they can't tell you what percentage of time it contributes to the run-time of a real-world application.)

The end result is that nothing gets done because nobody can agree on anything.

So what I'm suggesting is something different:

I'm worried that the Lua approach to implementing delegation by
fallbacks would not be amenable to efficient implementation.

You're missing the point. I am not saying that Forth should adopt the actual mechanisms used by Lua. Instead, I am pointing out that the Lua language (just like Forth) doesn't offer objects as a primitive type. What Lua does instead is to provide meta-mechanisms and some minor syntactic sugar that allows programmers to create and use objects with whatever kinds of semantics make sense for the programmer and application.

The end result is that there are a several OO systems available for Lua, each with different strengths, weaknesses, and properties. The programmer isn't stuck with any one particular model. They can pick and choose and even modify as their style, temperament, experience, and needs of their applications warrant:

One thing the Lua approach would do is maker it easier to use several
different styles of OO in a single program; interesting, but I'm not
keen on that.

I am. It works wonderfully, although like most power-tools, if you don't know what you're doing, you can get hurt. Unlike languages like C++ or Java or others that have a single notion of what an object is, Lua lets you build your own systems. But more importantly, these systems are all built on the *same* underlying meta-mechanisms. So they, in general, are interoperable, allowing for code sharing between them.

So if I want to use a library that favors class-based objects along with a library that thinks prototype-based objects are the way to go, I can. I'm not locked into a singular notion of what an object is. That kind of freedom is what scares some people and allows others to take flight.

On the other hand, Lua does make me realize that OO support can
(should?) be layered so that it is easy to implement different models
that use a common core.

Exactly. That's what I've been advocating. I'm not saying that Forth needs to implement Lua-style tables and meta-methods. I am saying that I believe that if the people who advocate the various OO systems for Forth would stop thinking in terms of why their OO system is the best and instead focus on factoring what is common between their systems, the result would be a set of primitives that they could layer their OO system on top of.

The benefits would be:

1. Replacing the endless arguments over individual OO systems with a meta-discussion on factoring out the common essential parts. That is, it seems more useful to get these people to work together for a common goal instead of watching them just continue to entrench themselves deeper and deeper. Well, there is some minor amusement value in it, but I'd like to see Forth move forward.

2. It helps demystify OO for people who don't understand OO. This is because the essential mechanisms are abstracted and can be discussed. In exactly the same way that Forth abstracts the implementation details of the dictionary behind words like ', being able to abstract the underlying mechanisms used by OO systems makes it easier to understand because you're focusing on the what, not the how.

3. It reinforces that Forth is all about choice. Aside from choosing your particular OO model, you're also free to not choose OO at all; the Forth community wouldn't be elevating any particular OO system to be standard. But by adopting this more primitive set of facilities, it would be saying that supporting OO is something of value to the community.

4. It promotes innovation in OO by giving people a common base to work from. For example, most people know about class-based and prototype-based objects. But there are other object models as well (like Beta's patterns) and other opportunities for experimentation. If Forth was to say, "we're adopting this singular OO standard" then we would have essentially what C++ and Java programmers have now-- no flexibility in their OO systems, and no way to encourage the community to experiment with different models.

5. It would give objects that were interoperable with each other, so if someone (for example) wanted to integrate a web server written around one OO model with a database written around another OO model, they don't have to choose one or the other. They can be confident that although the underlying models might be different, they can still use both in one application.

It should be said that none of this would prevent anyone from coming out with a OO system that bypasses this common layer. If the goals of a particular OO system couldn't be met by coding against this common layer, then fine-- you end up with an OO system that operates like now-- it is it's own world, filled with the strengths and weaknesses of the approach. People can choose it instead of an OO system based on the common layer.
.

Relevant Pages

  • Re: what happened to hash-tables
    ... >> You already need hashtables anyway internally for implementing Common ... Many of the people on the committee had much more experience ... The ANSI standard is about memorializing the "Common" practice ... Suppose that the winning extensible hash table protocol is based ...
    (comp.lang.lisp)
  • Re: Cohens paper on byte order
    ... A normal user (a programmer working with a common ... the program of the recipient. ... transmission of the AES block. ... defined 'standard' functions for doing the conversion ...
    (sci.crypt)
  • Re: Modernizing Common Lisp
    ... standard supported bindings. ... models and socket abstractions that are common enough for standardization. ... hard to inject libraries to write portable code is a good thing? ... but with incompatible interfaces (sort of like the problem ...
    (comp.lang.lisp)
  • Re: Help with floating point non-reversibility
    ... too common. ... programmers like you" you mean programmers who kept correcting your rookie ... while sweeping on to the grand fallacy, which here, I think, is the ... use of floating point to model the behavior of discrete individuals. ...
    (comp.programming)
  • CfV: [DEFINED] and [UNDEFINED]
    ... You find the actual ballot further down, ... The need for a standard word to find whether some Forth word has ... The spelling proposed here is one of the common ones, ... so it would seem that conforming to a standard spelling ...
    (comp.lang.forth)