Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  11:29[Войти] | [Зарегистрироваться]
Обсуждение темы:
Оберон-технология: особенности и перспективы


Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение. 

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 6256 сообщений

Добавить свое сообщение

Отслеживать это обсуждение

Обсуждение из раздела
Школа ОБЕРОНА

<<<... | 4186—4177 | 4176—4167 | 4166—4157 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 209


№ 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 с "пайпами"...
 AVC


№ 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) в тело подпрограммы, за что его жестко и справедливо критиковали адепты структурного программирования».

Аналогия с Фортраном не вполне ясна.
К обероновскому модулю можно обратиться только через интерфейс и никак иначе. (Никаких "дополнительных точек".)
Оберон имеет средства ограничения "буйства жизни" :) не только на уровне подпрограмм (структурное программирование), но и на уровне модулей (модульное программирование; среди таких средств: обращение только через интерфейс модуля, ацикличность (иерархичность) модульной структуры и т.д.).
Сейчас я хочу обратить внимание на один момент.
Надежность системы зависит от соблюдения заложенных в нее инвариантов.
(Одна из любимых цитат оберонщиков: "Надежность -- это инварианты, принятые всерьез".)
За инварианты внутри модуля отвечает разработчик модуля, и никто другой.
В частности, именно он закладывает возможность/невозможность замены какого-либо предоставляемого модулем сервиса "на лету".
Это примерно то же самое, что и разница между переменной и константой.
Иногда такая замена допустима, иногда нет.
 AVC


№ 4167   19-04-2007 03:35 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4166« (info21)
___________________________
И для того, чтобы, наконец, сформулировать эту очевидную мысль, нужно было ломиться зиллионом постов??
Хм?.. Посмотрите на »сообщение 3856« , разве там не эта мысль была сформулирована?..


<<<... | 4186—4177 | 4176—4167 | 4166—4157 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 209


Добавить свое сообщение

Отслеживать это обсуждение

Дополнительная навигация:
Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру
  
Время на сайте: GMT минус 5 часов

Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter.
Функция может не работать в некоторых версиях броузеров.

Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

 
© При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

Яндекс цитирования