====== Meta OOP ======

This project is an attempt to solve the problem we have with our many incompatible OOP packages.

===== Current Situation =====

  * We already have a gazillion of OOP packages.
  * The all suck in one way or the other.
  * Especially there's no interoperability between them, and they are wildly different, making it a maintanence nightmare if you want to support several of them.
  * People won't abandon their code base, i.e. the different syntax and semantics of various OOP packages can't change quickly.
  * Egos are in the way (NIH-syndrome)
  * Not understanding what OOP really is is in the way.

===== Food for Thoughts =====

Andrew Haley proposed two books and a paper to read:

  * [[http://www.amazon.com/Art-Metabobject-Protocol-Metaobject/dp/0262610744/|The Art of the Metaobject Protocol]]
  * [[http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/|Design patterns: elements of reusable object-oriented software]]
  * [[http://piumarta.com/pepsi/objmodel.pdf|Open, reusable object model]]
  * [[http://en.wikipedia.org/wiki/Design_pattern_(computer_science)|Design Patterns in Wikipedia]]

Note that the design patterns that emerged over the last two decades were obtained mostly in more static languages like Java, so a Forth system should do better, and allow more agile ways to work with OOP.


===== Solution =====

Common Lisp had the same problem, and the solution was to use a "metaobject protocol" that allows the user to specify what kind of OOP he exactly wants to have - these different OOPs then all are interoperable and work together.  The idea thus is to analyze common practice, to figure out what a good OOP needs to have (by looking at other languages), and put that all then together into a metaobject protocol (MOP), i.e. a set of words that allow people to implement and adapt OOP systems to their needs without causing maintenance nightmares and lack of interoperability.

As everybody understands something different from OOP, I want now first to list the concepts that need to be implemented.

==== Records and Namespaces ====

The starting point of Forth OOP (e.g. Dick Pountain's book [[http://www.amazon.com/gp/offer-listing/0125635702/|Object-oriented Forth: implementation of data structures]]) was records in their own namespace, and some words defined in that namespace, i.e. early binding default, late binding maybe with wordlist search or other awkward techniques.

Requirement of the MOP: provide namespaces, manage one-shot lookup into this namespaces.

==== Vtables ====

The vital structure for efficient late-binding is called a "vtable".  It contains pointers to methods in a efficient data structure - usually an array or a hash table.  The paper linked above suggests to use closures instead of function pointers, that would be an additional indirection.  The vtable should be able to manage itself, and different vtable implementations should coexist nicely within one system; i.e. the vtable itself has to be an object, too.

==== Recognizers ====

Anton Ertl [[http://groups.google.com/group/comp.lang.forth/msg/f70a9ea205b5b75a|proposed recognizers some time ago in comp.lang.forth]].  Matthias Trute generalized the idea, and actually implemented it in amForth 4.3 (see [[http://www.forth-ev.de/filemgmt/visit.php?lid=386|VD 2011-02]], pages 14ff.).
===== Examples of Current State =====

Klaus Schleisiek made his and Manfred Mahlow's OOP available for Gforth 0.6.2.

  * {{ks-oop.zip|Sources in a Zip file}}
  * {{ks-oop-11-10-03.zip|Updated sources in a zip file}}
  * {{ks-oop.pdf|PDF glossary}}

For all of you who don't understand what [[http://en.wikipedia.org/wiki/Late_binding|late binding]] and [[http://en.wikipedia.org/wiki/Virtual_method_table|vtables]] are, the small [[http://bernd-paysan.de/mini-oof.html|mini-oof]] epxlains it.