Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 4176 19-04-2007 04:54 | |
Ответ на »сообщение 4172« (AVC)
___________________________
>> Честно ответьте (не мне, а себе) на простой вопрос: "Подпрограмма одного модуля может обраться к подпрограмме другого модуля (даже с учетом того, что области export и import правильно оформлены)? Может или нет?".
Это не очень приятно... но с этим придется научиться жить...
> Может, если вызываемая подпрограмма экспортирована другим модулем.
Конечно, экспортирована (я же указал, что экспорт и импорт обоих модулей правильно оформлены)... Значит может... Тогда придется долго-долго убеждать программистов в том, что... делать-то они это могут... но это не хорошо... и не забывать пальчиком погрозить :)
А что тут такого уж неприятного?
С этим живем... и неплохо живем... :)
Кто-то (не Вы) говорил мне про каменный век... Там тоже жили и неплохо... наверное...
Для того в Обероне и модули, а не отдельные программы-процессы, чтобы можно было регулировать общение "напрямую".
А иначе -- UNIX с "пайпами"...
Да, уж лучше UNIX... для меня по-крайней мере...
Тогда у меня остался только один вопрос: «Почему адепты Oberon в одном случае отстаивают простоту и строгость, а в другом аналогичном случае – сложность и халатность? Когда же им верить?»...
№ 4175 19-04-2007 04:39 | |
Ответ на »сообщение 4158« (ASU)
___________________________
И суть моего предложения состоит в том, чтобы вы подумали над этим на досуге.
Подумать над этим стоит. И можно даже назвать этап, на котором в Оберонах гарантировано появятся средства систематического управления "массивами" модулей.
Это станет особенно необходимым (а значит - найдутся силы на реализацию), как только какая-либо Оберон-ОС (видимо, это будет Бутылка или что-то на ее основе) выйдет "из пеленок" и потребуется разграничение ныне единого модульного пространства по приложениям, пакетам или чему-нибудь там еще...
№ 4174 19-04-2007 04:36 | |
Ответ на »сообщение 4169« (ASU)
___________________________
Честно ответьте (не мне, а себе) на простой вопрос: "Подпрограмма одного модуля может обраться к подпрограмме другого модуля (даже с учетом того, что области export и import правильно оформлены)? Может или нет?".
Это не очень приятно... но с этим придется научиться жить...
Нет, не может. Порядок доступа определятся модулем.
№ 4173 19-04-2007 04:31 | |
Ответ на »сообщение 3856« (ASU)
___________________________
Систему образуют сущности и отношения. Отношения формируют связи (будем считать, что отношение и есть связь). Сущности и связи (их виды, правила комбинирования и т.п.) определяются конкретными этапами разработки (формулировка требований, моделирование, проектирование, макетирование, реализация и т.п.), на которых могут применяться разные подходы. То, как отображаются сущности и связи проекта (архитектуры) на сущности и связи реализации (языка программирования), определяется множеством факторов (выбором методологии, условиями конкретного проекта и т.п.).
Оберон-модули можно рассматривать как универсальные сущности (объединяющие, например, архитектуру и реализацию), а можно -- как специализированные сущности (на уровне архитектуры можно оперировать не в терминах модулей -- зависит от методологии).
Применительно к обсуждаемому вопросу. Если программист явно указывает связи между модулями, то он поступает... противоестественно, поскольку на уровне отдельного модуля решает вопросы системообразования. Правильное, с позиции теории систем, решение это декларировать потребности (импорт) и возможности (экспорт) в терминах интерфейсов. А что система "подставит" в качестве "поставщиков" или "потребителей" услуг (сервисов), это ее дело, но никак не прикладного программиста.
Какое удивительное непонимание сути! Спустя неделю воз и ныне там. Такое ощущение, что обсуждение носит полудуплексный характер (только на передачу, но не на прием).
1. Возможности -- это перечень (список, структура) имен сущностей (с указанием/без указания их атрибутов).
2. Потребности -- это обращение к сущностям по именам (с указанием/без указания атрибутов и их значений).
Как только в некоем языке (в каком-либо идентифицированном блоке исходного текста -- процедура, метод, модуль и т.д. и т.п.) называется сущность, тут же устанавливается связь вида: "блок --> имя_сущности".
Связь "имя_сущности --> реализация_сущности" может формироваться как напрямую (без интерфейса, локальные сущности), так и опосредованно (через интерфейс, внешние сущности). Связь интерфейса с реализацией_сущности может осуществляться либо на этапе компиляции, либо на последующих этапах (линковки, загрузки, исполнения).
Теперь конкретизируем язык. В языке Оберон/КП:
1. Имена сущностей с атрибутами декларированы/описаны в интерфейсах (спецификациях, DEFINITION).
2. Реализации сущностей выполнены/объявлены в реализациях (модули, MODULE).
3. Категорически запрещается обращаться к внешним сущностям, минуя интерфейсы (пресекается языком, на уровне компилятора).
4. Связь блока с именем_сущности может выполняться как на этапе компиляции (локальные сущности модуля), так и на последующих этапах ( любая внешняя сущность).
5. Связь интерфейса с реализацией_сущности может выполняться как жестко (один интерфейс -- одна реализация), так и гибко (один интерфейс -- несколько реализаций). Связь специфицируется на этапе компиляции, а воплощается на последующих этапах (любом из них).
Сущность "процедура" языка программирования совсем не обязательно должна соответствовать сущности "процедура" уровня требований (где под процедурой может подразумеваться процедура регистрации некоего физического лица) и сущности "процедура" уровня проекта. Аналогичным образом и в случае модуля -- модуль организационной структуры (юридический департамент) может не соответствовать модулю языка программирования -- зависит от выбранных схем отображения (требования --> проект --> реализация).
Семантическая перегрузка терминов (особенно справедливая в отношении слов "модуль" и "система") -- не повод заниматься рассуждениями архитектора на уровне инженера с попыткой доказать последнему, что его инструментарий и материалы никогда и ни за что не смогут воплотить грандиозные замыслы великого зодчего. Архитектор в делах инженера, увы, не копенгаген.
Еще какие-то вопросы остались?
№ 4172 19-04-2007 04:07 | |
Ответ на »сообщение 4169« (ASU)
___________________________
Честно ответьте (не мне, а себе) на простой вопрос: "Подпрограмма одного модуля может обраться к подпрограмме другого модуля (даже с учетом того, что области export и import правильно оформлены)? Может или нет?".
Это не очень приятно... но с этим придется научиться жить...
Может, если вызываемая подпрограмма экспортирована другим модулем.
А что тут такого уж неприятного?
С этим живем... и неплохо живем... :)
Для того в Обероне и модули, а не отдельные программы-процессы, чтобы можно было регулировать общение "напрямую".
А иначе -- UNIX с "пайпами"...
№ 4171 19-04-2007 04:07 | |
Ответ на »сообщение 4166« (info21)
___________________________
О/КП позволяет себя легко "достраивать" (AOS, Active BlackBox etc.)
Мои извинения И.Ермакову за "легко".
Все, конечно, относительно.
Но 4 человеко-месяца, даже если человек талантлив, для подобной достройки -- это, все-таки, скорее "легко" в подобном контексте.
№ 4170 19-04-2007 04:03 | |
Ответ на »сообщение 4167« (ASU)
___________________________
Ответ на »сообщение 4166« (info21)
___________________________
И для того, чтобы, наконец, сформулировать эту очевидную мысль, нужно было ломиться зиллионом постов??
Хм?.. Посмотрите на »сообщение 3856« , разве там не эта мысль была сформулирована?..
Хм.. Это называется "сформулирована"?..
№ 4169 19-04-2007 03:54 | |
Ответ на »сообщение 4168« (AVC)
___________________________
Аналогия с Фортраном не вполне ясна.
К обероновскому модулю можно обратиться только через интерфейс и никак иначе. (Никаких "дополнительных точек".)
У нас разные точки/масштабы рассмотрения... Ну, не нравится сравнение с Фортраном, не смотрите на него... я же не настаиваю. Честно ответьте (не мне, а себе) на простой вопрос: "Подпрограмма одного модуля может обраться к подпрограмме другого модуля (даже с учетом того, что области export и import правильно оформлены)? Может или нет?".
Это не очень приятно... но с этим придется научиться жить...
№ 4168 19-04-2007 03:38 | |
Ответ на »сообщение 4158« (ASU)
___________________________
То, что я хотел сказать здесь, я уже сказал: «Oberon, в том виде, котором он есть сейчас хорошо реализует принципы структурного программирования, и потому его удобно использовать для написания подпрограмм и модулей. Но он нарушает системные принципы, правильнее было бы сказать, что не запрещает нарушать системные принципы, не формирует культуру построения систем, как, в свое время, Фортран не запрещал оформлять дополнительные точки входа (entries) в тело подпрограммы, за что его жестко и справедливо критиковали адепты структурного программирования».
Аналогия с Фортраном не вполне ясна.
К обероновскому модулю можно обратиться только через интерфейс и никак иначе. (Никаких "дополнительных точек".)
Оберон имеет средства ограничения "буйства жизни" :) не только на уровне подпрограмм (структурное программирование), но и на уровне модулей (модульное программирование; среди таких средств: обращение только через интерфейс модуля, ацикличность (иерархичность) модульной структуры и т.д.).
Сейчас я хочу обратить внимание на один момент.
Надежность системы зависит от соблюдения заложенных в нее инвариантов.
(Одна из любимых цитат оберонщиков: "Надежность -- это инварианты, принятые всерьез".)
За инварианты внутри модуля отвечает разработчик модуля, и никто другой.
В частности, именно он закладывает возможность/невозможность замены какого-либо предоставляемого модулем сервиса "на лету".
Это примерно то же самое, что и разница между переменной и константой.
Иногда такая замена допустима, иногда нет.
№ 4167 19-04-2007 03:35 | |
Ответ на »сообщение 4166« (info21)
___________________________
И для того, чтобы, наконец, сформулировать эту очевидную мысль, нужно было ломиться зиллионом постов??
Хм?.. Посмотрите на »сообщение 3856« , разве там не эта мысль была сформулирована?..
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|