Набор мыслей на тему ООП.

Считайте это дневником. А то замучался исчиркивать бумажки, потом всё терять и вспоминать заново... Попробую восстановить последние мысли.

Реализация "внутри":
- Полная перезагрузка "стандартных" слов. Чтобы не мучаться с odup, o+, и прочими o.
- Стек объектов предположительно динамический, в виде связного списка. Т.о. в стеке можно хранить не ссылки на объекты, а сами объекты.
- Типизация. Каждый объект принадлежит определённому классу.
- Любой объект может быть одновременно идентификатором класса.
- Привязка функций статическая, но с подменяемыми таблицами. Т.е. для каждый метод имеет уникальный индекс в системе (одно имя - один индекс), для каждого класса есть таблица этих методов.
- Тип any (или т.п.) - "безтиповый" тип, аналогичный переменным PHP.

Определённые параметры функций. Скажем:

1/int ) fact 1 ;
n/int ) fact n 1- recurse n * ;

Определение факториала в духе Haskell'а.

- В строковых переменных возможны подстановки переменных в духе Perl/PHP (в случае типизации, понятно, делается попытка привести переменную к строковому типу).

Что-то в духе:

autostrings on  всё, что не определено - строка. 
                Для уменьшения числа кавычек

D:/Work/html2fb2/ДМБ-2010.htm file get  считать файл
r null replace                         замена 0D
<!DOCTYPE.+?> null gis  preplace        регексп. замена

 Обрамляем результат в <XML>n..n<XML>
 %0% - это вершина стека

"<XML>
%0%
</XML>"

out.fb2 file put   пишем файл

[/html_font]

%n% - n-й элемент в стеке
%ARG[n]% - n-й аргумент ком. строки
%ENV[key]% - окружение

Теперь собственно про объекты. Синтаксис в духе:
[html_font color=blue]

object complex
 private
  var i/float
  var j/float
 public
  : .   "(%i ,%j )" . ;
   y/complex x/complex ) +   
        x i  y i  +  x i !
        x j  y j  +  x j !
        nip ;
   int ) new  
    super new  обращение к суперклассу
    rot over i ! ;

Блин. Смайлики забыл отключить. Отключаю. А то -

Списки

{ null Январь Февраль Март Апрель Май Июнь Июль Август Сентябрь Октябрь Ноябрь Декабрь } value месяц

месяц{2} .

{
    { 1 "Январь"  }
    { 2 "Февраль" }
} hash like value s

hash - объект
like - приведение к типу объекта

Что-то по типу ML выходит

Угу, видимо. Тут в немалой степени видно влияние Haskell/O'Caml, которые сами наследники ML

А наследование и перегрузка операторов как? А со scope? Если все функции виртульные, то надо подумать как работать в конструкторах с переопределенными методами.

Каждый метод имеет уникальный индекс, каждый класс - свою таблицу вызовов, так что затраты на вызов минимальные, все операторы перегружаемые, наследование множественное и т.п.

1. {
2.     { 1 "Январь"  }
3.     { 2 "Февраль" }
4. } hash like value s

Гы. Тема попалась древняя... Однако, хотя ООП так и не понадобился, вот это реально работает :

1. {
2.     { 1 "Январь"  }
3.     { 2 "Февраль" }
4. } value arr
5.  
6. arr .
7.  
8. Вывод> [[1, Январь], [2, Февраль]]
9.  
10.  
11. new-hashmap
12. "Январь" => 1
13. "Февраль" => 2
14. value hash
15.  
16. hash .
17.  
18. Вывод> {2=Февраль, 1=Январь}
19.  
20. hash "1" m@ .
21.  
22. Вывод> Январь

Balancer> Каждый метод имеет уникальный индекс, каждый класс - свою таблицу вызовов, так что затраты на вызов минимальные, все операторы перегружаемые, наследование множественное и т.п.

Инхеританс, как известно, брейкает инкапсулайшн. Надо предусмотреть явное запрещение наследования. И может быть, хорошо бы иметь явный признак immutable объекта.

Сергей-4030> хорошо бы иметь явный признак immutable объекта.

Проект, где это могло бы пригодиться, всё равно не состоялся.

А теперь уже и ситуация на рынке совсем иная, за 4 года многое переменилось.

Скорее всего, если и придётся вернуться к ООП на Форте, то это будет просто конструктор классов для Java.