ASU >> как Вы собираетесь, не останавливая систему, перегрузить ее?

СГ > Да обычно. Оберон системы-то модульные. Более не нужные модули выгружаю, а новые загружаю.

Вообще, на таком высоком уровне абстракции трудно ответить более конкретно.
Может быть Вы какой-нибудь конкретный пример предложите? Подумаем...

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

А эти модули откуда возьмутся?

Новые модули надо или написать, или купить, или новое - это хорошо забытое старое.

как Вы собираетесь, не останавливая систему, перегрузить ее?

Да обычно. Оберон системы-то модульные. Более не нужные модули выгружаю, а новые загружаю.

заменить SQL на Oberon... Удобно?

При чём тут это?

Ответ на »сообщение 170« (12)
___________________________
Дело в том, что внутри одного языка может быть несколько уровней абстракции.
Безусловно... И каждый уровень абстракции требует своих собственных инструментальных средств... Например, тот же ассемблер, как правило, содержит в себе два языка: нотацию машинного кода и макроязык. И это сочетание позволяет создавать очень удобные и полезные абстракции (а-ля шаблоны, например). Если желаете, могу проиллюстрировать... А Оберон на каждом уровне абстракции остается Обероном со всеми своими неизменными плюсами и минусами...

Ответ на »сообщение 169« (AVC)
___________________________
ASU> А что предлагаете Вы? Перекомпилировать программу каждый раз, когда появляются новые требования (новые виды возмущений, логики их обработки, изменения структуры)?.. Вот она прелесть моноязычности: гарантированная корка черствого хлеба... :)

Хм... а Вы точно говорите об Обероне?
Нет, об Обероне (в диалоге со мной) говорит Сергей Губанов, а я говорю о том, что необходимо отказаться от моноязычности (даже безотносительно к Оберону).

Как раз Оберон позволяет создавать динамические модульные системы, где конкретная конфигурация модулей определяется (и меняется) во время работы, а новые типы сообщений могут создаваться и циркулировать по программной шине без перекомпиляции и перезагрузки работающих модулей.
См. ответ на »сообщение 172«

Ответ на »сообщение 164« (Сергей Губанов)
___________________________
ASU> А что предлагаете Вы? Перекомпилировать программу каждый раз, когда появляются новые требования (новые виды возмущений, логики их обработки, изменения структуры)?..

Так всё же наоборот!!! Использование сообщений вместо вызова (виртуальных) методов позволяет не перекомпилировать старые модули (и не выгружать их; и не останавливать работающую систему) при динамическом добавлении (загрузке) в систему нового модуля с новыми типами сообщений
"Увы мне, увы..."

Не останавливая систему, не выгружая старые модули:
1) Загружаем в систему новый (только что написанный модуль) с новыми типами сообщений:
MODULE NewMessages;

  IMPORT BasicMessages;

  TYPE
    Msg1* = RECORD (BasicMessages.Message)
      (* ... *)
    END;

    Msg2* = RECORD (BasicMessages.Message)
      (* ... *)
    END;

END NewMessages.

2) Загружаем в систему новые модули умеющие посылать и обрабатывать эти новые сообщения.
А эти модули откуда возьмутся? Это первый вопрос. Второй... Можно легко показать, что ретрансляция сообщений на вложенные сущности (объекты) по определенной схеме - это и есть "код" самой системы (по крайней мере большая его часть). Другими словами, как Вы собираетесь, не останавливая систему, перегрузить ее? Вы думаете я случайно говорил об интерпретаторах на этом логическом уровне?

3) Далее возможны варианты от тривиального: старые объекты/модули просто игнорируют новые типы сообщений, до нетривиального - когда новые объекты/модули "прописывают/внедряют/регистрируют" свои новые обработчики "внутрь" старых объектов и, тем самым, "старые" объекты динамически преобретают способность реагировать на новые типы сообщений
Сергей, не спешите. Прочитайте внимательнее то, что я написал ранее... про различие логик у разных уровней... Попробуйте, для примера, заменить SQL на Oberon... Удобно?..

Ответ на »сообщение 161« (Сергей Губанов)
___________________________
ASU> счетчик

Хе-хе-хе... ;-)
Так счётчик - это и есть сборщик мусора!!! Правда очень простой и самодельный, но бывают посложнее и встроенные. Но без них-то, простых или сложных, и не туды и не сюды...
Увы... Сергей, "счетчик" - это гораздо больше, чем "сборка мусора"... Во-первых, "счетчик" можно использовать по отношению к любому разделяемому ресурсу, а не только в целях "очистки" памяти. Во-вторых, можно использовать "счетчик" для разделения доступа,  на основе блокировок (встроив в него критические секции, семафоры, мьютексы и пр.) или версий. То есть, функциональное наполнение "счетчика" гораздо больше, чем "сборка мусора". В-третьих, если вернуться к рассмотрению Вашего примера, то можно заметить, что работа со "счетчиком" описана в одном месте, а, следовательно, отлаживать и контролировать ее значительно проще. Вы же говорили о том, что Ваша переменная dir может быть использована разными программистами в разных модулях, то есть, проконтролировать использование dir более трудоемкая (я бы сказал ошибкоемкая) задача.
PS. Если Pascal, а затем и Modula2 воспитывали в программистах умение декомпозировать код по подпрограммам, то Oberon, в этом смысле, не сделал даже маленького шажка вперед, оставшись на том же уровне... IMHO. И тот пример, что Вы привели, просто иллюстрирует то, что "хороший стиль" Oberon, увы, не развивает. А жаль... искренне...

Вы предлагаете и тот и другой уровни написать монолитно и на одном языке.ASU

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

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


А что предлагаете Вы? Перекомпилировать программу каждый раз, когда появляются новые требования (новые виды возмущений, логики их обработки, изменения структуры)?.. Вот она прелесть моноязычности: гарантированная корка черствого хлеба... :)


Хм... а Вы точно говорите об Обероне?
Как раз Оберон позволяет создавать динамические модульные системы, где конкретная конфигурация модулей определяется (и меняется) во время работы,
а новые типы сообщений могут создаваться и циркулировать по программной шине без перекомпиляции и перезагрузки работающих модулей.

Ответ на »сообщение 167« (11bis)
___________________________


Спасибо, но в этой ОС, назовем ее Ceres Oberon, нет компиляторов C++ и C#.
То есть как я понимаю речь идет о чистом теоретизировании.


Я и не утверждал обратного.
Я сказал, что в ОС Оберон нет принципиальных ограничений на использование SQL, скриптовых и декларативных языков.
А вот использовать C++ без ограничений -- принципиально невозможно.

Ответ на »сообщение 165« (AVC)
___________________________
Спасибо, но в этой ОС, назовем ее Ceres Oberon, нет компиляторов C++ и C#.
То есть как я понимаю речь идет о чистом теоретизировании.