Ответ на »сообщение 3965« (Sergei)
___________________________

В Blackbox была один в один имитирована архитектура Oberon V2...

Уважаю глубоко копающих.

Respect.

Ответ на »сообщение 3968« (Как слышно? Прием!)
___________________________

Любите рекурсивные определения? Хорошо. Как Вы найдёте эти:
Расстояние -- величина, характеризующая расстояние от одного объекта до другого.
Множество целых чисел -- множество, каждый элемент которого является целым числом. Целое число -- элемент множества целых чисел. (неявная рекурсия)

Можно ещё кучу напридумывать, большей частью тривиальные.

Ответ на »сообщение 3961« (ASU)
___________________________

Об инструментальном подходе при построении больших систем можно посмотреть публикации на http://www.alexus.ru/russian/articles.htm


У меня один наивный вопрос.
Я нашел у Вас интересное утверждение, что разделение полиморфизма и виртуальности (наследования) позволяет решить многие проблемы.
Вот мой вопрос.
Позволяет ли обероновский подход с "обработчиками" добиться того же самого?
Вот пример обработчика в классическом Обероне:

PROCEDURE Handle(me: Object; VAR msg: Message);

Здесь в числе аргументов обработчика содержатся как сам объект, так и сообщение. Значит, здесь задействованы одновременно две иерархии -- объектов и сообщений.
Приведенные Вами примеры со свойствами "иметь цветы" и "иметь плоды" в Си++, наверное, могли быть реализованы как примеси, а в Обероне (имхо) с помощью обработчиков.
Вы имели в виду что-то похожее, когда писали об отделении полиморфизма от наследования, или нет?

Предлагаю такую зацепку для определения модуля. Модуль и тип данных не тождественны (в отличие от классов и типов данных). Да по-моему, эта мысль уже высказывалась кем-то из участников дискуссии.

Ответ на »сообщение 3981« (Takun)
___________________________


Класс не может. Объекты класса мы сейчас вроде не рассматриваем.


Объекты класса? Это ж вроде экземпляры. Вы может быть путаете классы с метаклассами, а объекты класса с классами?


Таки не было дано определения модуля и модульного языка программирования. В Limbo может, например.


Тогда это уже класс.

Ответ на »сообщение 3975« (Сергей Губанов)
___________________________

Ну а определение модульной системы, может, приведёте всё-таки?
А то пример с программой в исходных текстах в качестве модульной системы вполне проходит.

Ответ на »сообщение 3981« (Takun)
___________________________

Скажите, может ли один и тот же класс в языке Eiffel иметь несколько экземпляров (своих представителей)?

Класс не может. Объекты класса мы сейчас вроде не рассматриваем.

Насколько я понимаю (знающие люди меня поправят), в ООП экземпляр (представитель) класса и называется объектом. При такой трактовке в языке, поддерживающем концепцию класса (Eiffel -- пример такого языка), один и тот же класс может иметь несколько экземпляров.

Скажите, может ли модуль в языке модульного программирования иметь несколько несколько экземпляров (своих представителей)?

Таки не было дано определения модуля и модульного языка программирования. В Limbo может, например.

Так мы и занимаемся тем, что пытаемся выяснить особенности модуля и через это подойти к тому, чтобы дать ему более-менее удовлетворительное определение (полезное в работе).

Насчет Limbo не скажу, не знаю. Можно посмотреть. В Аде есть generic-модули (т.е. родовые, параметризуемые модули). Их вполне можно рассматривать как модули, которые могут иметь несколько экземпляров. Если брать другие языки модульного программирования -- Modula-2, Оберон-языки, то у них модуль всегда в одном-единственном экземпляре.

Это (уникальность модуля) можно рассматривать как особенность модулей (с поправкой на различные реализации в разных языках).

Ответ на »сообщение 3963« (Как слышно? Прием!)
___________________________

Продолжая сравнение модуля и объекта и аналогию с тортом.
Торт - это данные. Модуль - хозяйка с тортом. Объект - официантка с тортом.
С официанткой с тортом (если без хакинга) можно выполнить
ограниченный, но стандартный набор действий. Ex: Сказать: "Разрежьте!"
С хозяйкой с тортом Вы имеете возможность ... короче, это индивидуально
и многообразно, но в смысле употребления торта - регресс.
Потому, что суть не в том, чтобы углубляться, а в том, чтобы идти в нужном
направлении. На мой взгляд, нужное направление - выработка объектов
второго поколения, которые будут инкапсулировать не только данные
и операции, но и ещё кучу других аспектов.
При усложнении системы блоки должны быть больше и универсальнее.
При конструировании КАМАЗа движок использовали старый и проверенный -
с танка Т-34, а не разрабатывали из болтов , гаек, клапанов, прокладок, и т.п.
Повторное использование кода на основе объектного конструирования, так сказать.


Вы о чём? (Риторический вопрос)

Ответ на »сообщение 3953« (info21)
___________________________


"Модульных систем".
Но Вы сами разъясняете ("всё упирается в среду...") смысл, который пытается донести С.Г.


Не-а. Я представил только один аспект модуля, названный Русланом Богатырёвым операционным. И к тому же С.Г. отказал Delphi в праве называться модульным языком, а я показал, что программы, написанные на нём, могут быть представлены как раздельно-загружаемые модули.

Ответ на »сообщение 3977« (Takun)
___________________________
Другое замечание. Вирт славится своей любовью к однопроходным компиляторам, хотя стпепнь их модульности гораздо ниже (по Парнасу) чем у двухпроходных (с разделением frontend/backend).

И сколько же модулей в компиляторе Оберона?
По-моему как минимум 3:
- сканер;
- парсер;
- кодогенератор.
В некоторых реализация я видел и больше модулей...
Но компиляция при этом выполняется в один проход.
Под backend подразумевается кодогенератор, котороый может меняться в зависимости от целевой машины.