Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 176 21-06-2006 02:58 | |
ASU >> как Вы собираетесь, не останавливая систему, перегрузить ее?
СГ > Да обычно. Оберон системы-то модульные. Более не нужные модули выгружаю, а новые загружаю.
Вообще, на таком высоком уровне абстракции трудно ответить более конкретно.
Может быть Вы какой-нибудь конкретный пример предложите? Подумаем...
№ 175 21-06-2006 02:52 | |
Ответ на »сообщение 172« (ASU)
А эти модули откуда возьмутся?
Новые модули надо или написать, или купить, или новое - это хорошо забытое старое.
как Вы собираетесь, не останавливая систему, перегрузить ее?
Да обычно. Оберон системы-то модульные. Более не нужные модули выгружаю, а новые загружаю.
заменить SQL на Oberon... Удобно?
При чём тут это?
№ 174 20-06-2006 22:33 | |
Ответ на »сообщение 170« (12)
___________________________
Дело в том, что внутри одного языка может быть несколько уровней абстракции.
Безусловно... И каждый уровень абстракции требует своих собственных инструментальных средств... Например, тот же ассемблер, как правило, содержит в себе два языка: нотацию машинного кода и макроязык. И это сочетание позволяет создавать очень удобные и полезные абстракции (а-ля шаблоны, например). Если желаете, могу проиллюстрировать... А Оберон на каждом уровне абстракции остается Обероном со всеми своими неизменными плюсами и минусами...
№ 173 20-06-2006 22:27 | |
Ответ на »сообщение 169« (AVC)
___________________________
ASU> А что предлагаете Вы? Перекомпилировать программу каждый раз, когда появляются новые требования (новые виды возмущений, логики их обработки, изменения структуры)?.. Вот она прелесть моноязычности: гарантированная корка черствого хлеба... :)
Хм... а Вы точно говорите об Обероне?
Нет, об Обероне (в диалоге со мной) говорит Сергей Губанов, а я говорю о том, что необходимо отказаться от моноязычности (даже безотносительно к Оберону).
Как раз Оберон позволяет создавать динамические модульные системы, где конкретная конфигурация модулей определяется (и меняется) во время работы, а новые типы сообщений могут создаваться и циркулировать по программной шине без перекомпиляции и перезагрузки работающих модулей.
См. ответ на »сообщение 172«
№ 172 20-06-2006 22:22 | |
Ответ на »сообщение 164« (Сергей Губанов)
___________________________
ASU> А что предлагаете Вы? Перекомпилировать программу каждый раз, когда появляются новые требования (новые виды возмущений, логики их обработки, изменения структуры)?..
Так всё же наоборот!!! Использование сообщений вместо вызова (виртуальных) методов позволяет не перекомпилировать старые модули (и не выгружать их; и не останавливать работающую систему) при динамическом добавлении (загрузке) в систему нового модуля с новыми типами сообщений
"Увы мне, увы..."
Не останавливая систему, не выгружая старые модули:
1) Загружаем в систему новый (только что написанный модуль) с новыми типами сообщений:
MODULE NewMessages;
IMPORT BasicMessages;
TYPE
Msg1* = RECORD (BasicMessages.Message)
(* ... *)
END;
Msg2* = RECORD (BasicMessages.Message)
(* ... *)
END;
END NewMessages.
2) Загружаем в систему новые модули умеющие посылать и обрабатывать эти новые сообщения.
А эти модули откуда возьмутся? Это первый вопрос. Второй... Можно легко показать, что ретрансляция сообщений на вложенные сущности (объекты) по определенной схеме - это и есть "код" самой системы (по крайней мере большая его часть). Другими словами, как Вы собираетесь, не останавливая систему, перегрузить ее? Вы думаете я случайно говорил об интерпретаторах на этом логическом уровне?
3) Далее возможны варианты от тривиального: старые объекты/модули просто игнорируют новые типы сообщений, до нетривиального - когда новые объекты/модули "прописывают/внедряют/регистрируют" свои новые обработчики "внутрь" старых объектов и, тем самым, "старые" объекты динамически преобретают способность реагировать на новые типы сообщений
Сергей, не спешите. Прочитайте внимательнее то, что я написал ранее... про различие логик у разных уровней... Попробуйте, для примера, заменить SQL на Oberon... Удобно?..
№ 171 20-06-2006 22:12 | |
Ответ на »сообщение 161« (Сергей Губанов)
___________________________
ASU> счетчик
Хе-хе-хе... ;-)
Так счётчик - это и есть сборщик мусора!!! Правда очень простой и самодельный, но бывают посложнее и встроенные. Но без них-то, простых или сложных, и не туды и не сюды...
Увы... Сергей, "счетчик" - это гораздо больше, чем "сборка мусора"... Во-первых, "счетчик" можно использовать по отношению к любому разделяемому ресурсу, а не только в целях "очистки" памяти. Во-вторых, можно использовать "счетчик" для разделения доступа, на основе блокировок (встроив в него критические секции, семафоры, мьютексы и пр.) или версий. То есть, функциональное наполнение "счетчика" гораздо больше, чем "сборка мусора". В-третьих, если вернуться к рассмотрению Вашего примера, то можно заметить, что работа со "счетчиком" описана в одном месте, а, следовательно, отлаживать и контролировать ее значительно проще. Вы же говорили о том, что Ваша переменная dir может быть использована разными программистами в разных модулях, то есть, проконтролировать использование dir более трудоемкая (я бы сказал ошибкоемкая) задача.
PS. Если Pascal, а затем и Modula2 воспитывали в программистах умение декомпозировать код по подпрограммам, то Oberon, в этом смысле, не сделал даже маленького шажка вперед, оставшись на том же уровне... IMHO. И тот пример, что Вы привели, просто иллюстрирует то, что "хороший стиль" Oberon, увы, не развивает. А жаль... искренне...
№ 170 20-06-2006 12:34 | |
Вы предлагаете и тот и другой уровни написать монолитно и на одном языке.ASU Дело в том, что внутри одного языка может быть несколько уровней абстракции.
№ 169 20-06-2006 11:11 | |
Ответ на »сообщение 162« (ASU)
___________________________
А что предлагаете Вы? Перекомпилировать программу каждый раз, когда появляются новые требования (новые виды возмущений, логики их обработки, изменения структуры)?.. Вот она прелесть моноязычности: гарантированная корка черствого хлеба... :)
Хм... а Вы точно говорите об Обероне?
Как раз Оберон позволяет создавать динамические модульные системы, где конкретная конфигурация модулей определяется (и меняется) во время работы,
а новые типы сообщений могут создаваться и циркулировать по программной шине без перекомпиляции и перезагрузки работающих модулей.
№ 168 20-06-2006 10:54 | |
Ответ на »сообщение 167« (11bis)
___________________________
Спасибо, но в этой ОС, назовем ее Ceres Oberon, нет компиляторов C++ и C#.
То есть как я понимаю речь идет о чистом теоретизировании.
Я и не утверждал обратного.
Я сказал, что в ОС Оберон нет принципиальных ограничений на использование SQL, скриптовых и декларативных языков.
А вот использовать C++ без ограничений -- принципиально невозможно.
№ 167 20-06-2006 10:43 | |
Ответ на »сообщение 165« (AVC)
___________________________
Спасибо, но в этой ОС, назовем ее Ceres Oberon, нет компиляторов C++ и C#.
То есть как я понимаю речь идет о чистом теоретизировании.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|