Ответ на »сообщение 1393« (Alexey Veselovsky)
___________________________

Ответ на »сообщение 1392« (Илья Ермаков)
___________________________
Повтори пожалуйста почему отказались от строгой субтипизации.
Потому что INTEGER+константы легко расширяется без перекомпиляции. Ввели новые константы, старые клиенты работают, ничего не зная о них. При субтипизации - одно из двух: либо введение в перечисление/диапазон новых элементов требуем перекомпилировать всех клиентов, и компонентность летит в..., либо требуется изобретать какой-то навороченный механизм расширения субтипов и контроля соответствия версий.

Ответ на »сообщение 1387« (Max Belugin)
___________________________
Я не вижу каким требованиям к модулю в обоих аспектах не удовлетворяет класс в Java. Хотя классы играют роль не только модулей
В том-то и беда, что классы семантически перегружены, на них вешаются две принципиально ортогональные задачи - асбтрагирование данных и абстрагирование архитектуры. Это грубое смешение с легкой руки Страустрапа прижилось в индустрии...

Тип данных - это одно, модуль - совсем другое. Типы данных вырабатываются на основе анализа и абстрагирования предметной области. Модули вырабатываются на основе проектирования архитектуры. Тип данных - это аналитика, модуль - это конструирование. В Обероне система строится из модулей, которые обмениваются по различного рода шинам объектно-ориентированными данными. ООП в Обероне выполняет две функции: абстракции данных и создание абстрактных разъемов для соединения модулей между собой. Все. Архитектурная нагрузка полностью лежит на отдельной конструкции (языковой, компиляторной, дистрибуционной, загрузочной) - модуле.

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


Я не понимаю, что хочет съесть эта функция.
Документацию почитайте.


И это все, что может предложить оберон?


Если уж такая простая вещь выходит из под Вашего контроля, то может Вам вообще не программировать?

Если даже такую простую вещь компилятор оберона не может проконтролировать, то может нафиг его, такой язык?

Ответ на »сообщение 1392« (Илья Ермаков)
___________________________

Ответ на »сообщение 1390« (pepper)
___________________________
Назначьте псевдоним:
TYPE
  Color = INTEGER,
и будет сразу видно, чем кормить функцию.
Однако накормить чем угодно ее компилятор не помешает, к сожалению.
Причины отказа от строгой субтипизации аля-Ада уже были названы.

Повтори пожалуйста почему отказались от строгой субтипизации.

Ответ на »сообщение 1390« (pepper)
___________________________
Назначьте псевдоним:
TYPE
  Color = INTEGER,
и будет сразу видно, чем кормить функцию.
Однако накормить чем угодно ее компилятор не помешает, к сожалению.
Причины отказа от строгой субтипизации аля-Ада уже были названы.
Как показывает практика, никакого принципиального ущерба от этого не замечается.
В Оберонах принята практика в начале каждой процедуры ВСЕГДА писать неотключаемый ASSERT - предусловие на входные параметры, а в документации на каждую процедуру специфицировать предусловие. Поэтому любые ошибки неверного входа моментально локализуются, так же как и источник неверных данных на входе.
В случае строгой субтипизации большая часть ошибок на этапе компиляции также не выплывет, т.к. ошибки встречаются в основном при передаче не констант, а переменных, поэтому для полной гарантии требуется рантайм-контроль границ субтипов (Ада его обеспечивает, если не отключим это в опциях компилятора). Однако контроль границ при каждом присваивании - согласитесь, это многократно более накладно, чем контроль корректности на входе процедур.

Ответ на »сообщение 1390« (pepper)

Я не понимаю, что хочет съесть эта функция.

Документацию почитайте.

Никто не помешает мне накормить эту функцию любыми константами

А ещё Вам никто не помешает разделить на ноль, разыменовать нулевой указатель, зависнуть в бесконечном цикле, переполнить стек и т.д..

Если уж такая простая вещь выходит из под Вашего контроля, то может Вам вообще не программировать?

Ответ на »сообщение 1389« (Владимир Лось)
___________________________

Перечислимый тип. Поскольку в обероне его нет, то больше заморочек при решении задач, где он востребован.
Ну-ка, ну-ка, приведите-ка конкретно эту заморочку, именно место "где болит". Обсудим... Со всех сторон.
(Хотя, повторять это в сотый раз очередному "новонаезжающему", да ещё упертому на своей позиции - марна праця)

Пока повторять приходится мне. Ладно, еще раз.
Проблема 1.
Видя декларацию вида:

PROCEDURE eat*(i: INTEGER);

Я не понимаю, что хочет съесть эта функция.

Проблема 2 является следствием проблемы 1.
Никто не помешает мне накормить эту функцию любыми константами:

CONST red* = 0; blue* = 1; green* = 2;
CONST apple* = 0; orange* = 1; mango* = 2;
...
eat(apple);
eat(red);

Перечислимый тип решает обе эти проблемы.

Ответ на »сообщение 1382« (pepper)
___________________________
Перечислимый тип. Поскольку в обероне его нет, то больше заморочек при решении задач, где он востребован.
Ну-ка, ну-ка, приведите-ка конкретно эту заморочку, именно место "где болит". Обсудим... Со всех сторон.
(Хотя, повторять это в сотый раз очередному "новонаезжающему", да ещё упертому на своей позиции - марна праця)

Ответ на »сообщение 1387« (Max Belugin)


модуль обладает двумя аспектами:
  *как единица логической структуры программы (типа unit в паскале)
  *как единица компиляции (с точки зрения инструментария)
  *как единица структуры развёртывания приложения (типа dll)
Я не вижу каким требованиям к модулю в обоих аспектах не удовлетворяет класс в Java.

Ну а теперь представьте что есть два класса взаимно друг о друге "знающих". Скомпилировать, загрузить/выгрузить можно только оба класса одновременно. Следовательно модулем является не каждый из них по отдельности а их совокупность. Что и требовалось доказать.

Ну а то что в частном случае модуль может состоять всего из одного класса ни о чём не говорит.
Вот, например, модуль может состоять из одного BYTE:

MODULE A;

  VAR a: BYTE;

END A.

и чего, значит BYTE - это модуль?

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

Ответ на »сообщение 1370« (Max Belugin)

Почему классы не являются модулями?

А почему Луна не является Солнцем?

Смысл у них разный. Поймите в чём состоит смысл класса и в чём состоит смысл модуля. Тогда поймёте ответ.
http://blackbox.metasystems.ru/index.php?option=com_content&task=view&id=36&Itemid=15

0. Я согласен с тем, что модульность в вашем понимании несколько труднее осуществить в распространенных средах чем в Обероне.

1. Скорее "Почему Солнце не является звездой" - модуль обладает двумя аспектами:
  *как единица логической структуры программы (типа unit в паскале)
  *как единица компиляции (с точки зрения инструментария)
  *как единица структуры развёртывания приложения (типа dll)
Я не вижу каким требованиям к модулю в обоих аспектах не удовлетворяет класс в Java. Хотя классы играют роль не только модулей

2. Не очень понятно, почему автоматическая выгрузка модуля зло, если у модуля нет состояния. Если у модуля есть состояние, выгружается ли он в Java (то есть если завести статическое поле нинциализировать его, позвать сборщик мусора - вернется ли оно в начальное состояние)?

...
Ответ на »сообщение 1378« (AVC)
___________________________

По поводу closures - даже в ОО closures помогают писать более лаконичный повторно используемый код. Например, попробуйте транслировать вот это:

http://martinfowler.com/bliki/Closure.html
http://boo.codehaus.org/Martin+Fowler's+closure+examples+in+boo