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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


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

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

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

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


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

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

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

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

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


№ 4166   19-04-2007 03:12 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4158« (ASU)
___________________________

И для того, чтобы, наконец, сформулировать эту очевидную мысль, нужно было ломиться зиллионом постов??

Отсутствие в Обероне каких-сложных вещей типа механизмов управления много-много-модульными системами (как и concurrency) -- это не утверждение об их (механизмов) ненужности, а об их непонятости -- при том, что в существующем виде Оберон/КП позволяет без особого труда моделировать практически любые схемы организации.  Также как О/КП позволяет себя легко "достраивать" (AOS, Active BlackBox etc.)


№ 4165   19-04-2007 03:01 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4163« (al_mt)
___________________________

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

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

Стало совсем интересно :) Я представил, как из системы выключается такая "системообразующая подсистема", как сервер БД. И никто этого не заметил. Или сервер БД не укладывается в ваше понятие "подсистемы"?

Вы будете смеяться, но мне довелось заниматься системой, для которой, мы сделали возможность "на горячую" перетыкать модули БД. Локальная/сетевая/никакой.

В случае "никакой" система сохраняла возможность работать с локальными файлами в XML. В принципе можно было сделать и автоматику, типа отваливается сетевая БД, клиент прозрачно переключается на локальную, даже не заметив этого :)))))))))


Охотно верю. Я сам подумывал о таком, но представив себе проблемы транзакций и последующей синхронизации в реал-тайм системе, вовремя отказался :)
Смысл-то несколько в другом, как мне кажется. Если можно любую подсистему отключить, и при этом система не перестанет быть "системой", тогда зачем называть эту подсистему "системообразующей"? Отрубили сервер, и централизованная система распалась на ряд кластеров. Это уже другая "система", согласитесь.



№ 4164   19-04-2007 02:53 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4128« (Сергей Перовский)
___________________________

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


№ 4163   19-04-2007 02:44 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4161« (Stargazer)
___________________________

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

Стало совсем интересно :) Я представил, как из системы выключается такая "системообразующая подсистема", как сервер БД. И никто этого не заметил. Или сервер БД не укладывается в ваше понятие "подсистемы"?


Вы будете смеяться, но мне довелось заниматься системой, для которой, мы сделали возможность "на горячую" перетыкать модули БД. Локальная/сетевая/никакой.

В случае "никакой" система сохраняла возможность работать с локальными файлами в XML. В принципе можно было сделать и автоматику, типа отваливается сетевая БД, клиент прозрачно переключается на локальную, даже не заметив этого :)))))))))


№ 4162   19-04-2007 02:41 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4156« (Илья Ермаков)
___________________________
Стоп. Прошу прощения. "Образует граф". Все верно. Граф, но ациклический направленный и иерархический.
Любая иерархия - это граф, но не всякий граф иерархия. Связи модулей на одном уровне (прямые или опосредованные), в общем случае и в Вашем примере, образуют направленный граф, в частном случае - иерархию.
Система делится уровни - здесь строго иерархическая структура.


№ 4161   19-04-2007 02:39 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4154« (ASU)
___________________________

Ответ на »сообщение 4152« (Stargazer)
___________________________
Пользуясь той же стилистикой, скажу: системная логика стога сена формируется на логике взаимодействия травинок. Иначе стог не был бы стогом.
Логику стога сможете раскрыть? Расскажите, мне интересно...

А вы... стог... сена видели? Для чего его делают... в курсе? Подумайте на... досуге.

Ничего себе. Летит самолёт, и вдруг у него отваливаются двигатели. Никто ничего не заметил, все продолжают лететь.
Всё чудесатее и чудесатее.
Если Вы не заметили, то повторю, что речь шла о нашей системе, а не о Вашем самолете. Ферштейн?.. «Блочный ремонт» без остановки для многих систем давно стал нормой... уважительного отношения к заказчикам/потребителям.


Стало совсем интересно :) Я представил, как из системы выключается такая "системообразующая подсистема", как сервер БД. И никто этого не заметил. Или сервер БД не укладывается в ваше понятие "подсистемы"?


№ 4160   19-04-2007 02:10 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4157« (Axcel)
___________________________
В системах, к разработке которых я когда-то имел отношение (системы управление РВСН - НПО "Импульс"), конечный пользователь никогда, ни при каких обстоятельствах, не имел права (и не имел никакой возможности) менять логику без привлечения разработчиков.  А вот, операторы Чернобыльской АЭС имели, если не право то, по крайней мере, возможность.  Так что, системы бывают разные, соответственно всякие там "возможности" или "невозможности" надо специально продумывать и специально закладывать. Насколько удобны Обероны для разработки систем  со  подобными "возможностями/невозможностями" ? Думаю, что удобны.
Вы случайно или намерено смешиваете два совершенно разных понятия: возможности системы и права пользователей. Я никогда не призывал ко вседозволенности, но я категорически не приемлю решений, которые не могут работать без их "авторов"... это кормушка для топ вечно... голодных "франчайзи"...


№ 4159   19-04-2007 02:06 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4088« (Сергей Перовский)
___________________________

.. Вместо FROM Math IMPORT Sin я бы предпочел неписать просто IMPORT Sin, а насчет From пусть болит голова у того, кто будет собирать из модулей систему - у него должен быть другой инструмент.


"Должен"?
Тут имеет место разведение полномочий -- важный момент, и если что "должно" быть, так это максимальная эксплицитность в отношении такого решения.

Чтобы я для всех внешних сущностей всегда писал From MyImportList, а в  MyImportList потом поставим каждому соответствующий модуль реализации. Только зачем повторять в десятках и сотнях строк From MyImportList?

Все равно нужно повторять в отдельных модулях описания интерфейса этого Sin.
"Зачем повторять" звучит как каприз.

Механизм, практически 1:1 аналогичный тому, что делает независимый линкер -- это сделать глобальную переменную для Sin, и заполнять ее из какого-нить Config или Setup, вызываемого при инициализации.

Короче, сия конкретная проблема ничтожна.




№ 4158   19-04-2007 02:00 Ответить на это сообщение Ответить на это сообщение с цитированием
Предложение для адептов Oberon
Уважаемые адепты, мне импонирует ваше трепетное отношение к простоте и строгости, к введению и контролю продуманных формализмов. Безусловно, это дает большой... нет, очень большой... положительный эффект и с точки зрения читабельности текста программ, и с точки зрения надежности кода.
Давайте рассмотрим один из примеров того, за счет чего это достигнуто. Развитие и становление структурного программирования в значительной степени обязано формированию культуры структуризации (декомпозиции) кода. Подпрограммы дали возможность не только сократить трудозатраты на написание программ, за счет использования библиотечных подпрограмм (единожды написанных и отлаженных), но и... Подпрограмма локализует свой код, нельзя, не нарушая принципов структурного программирования, перейти на любой оператор подпрограммы, минуя ее заголовок. К следствие, резко сократилось количество связей внутри самой программы. И именно развитие методов декомпозиции дало возможность отказаться от пресловутого оператора перехода GoTo... Программы перестали напоминать «спагетти».
Но на уровне модулей... история вновь повторяется. Любой модуль может обратиться к любому другому модулю, надо только указать его в списке импорта, как в случае GoTo надо было только объявить метку, куда будет осуществлен переход. Пока модулей («операторов») в программе относительно немного отслеживать переходы не составляет большого труда, но... что происходит при увеличении их числа?.. Система может содержать тысячи модулей. Как управлять этим «хозяйством»? Как отслеживать связи («переходы»)? Не в этом ли причина того, что даже внесение небольших изменений в систему приводит к... рефакторингу всего и вся.
В чем корень того упорства, с которым вы отрицаете необходимость структуризации модулей и введение специальных механизмов контролирующих их взаимодействие? Согласитесь, что подпрограмма – это не отдельный оператор, это структура кода. Точно также, подпрограмма «помогает» программе структурировать код, кто должен помочь системе структурировать взаимодействие модулей.

И суть моего предложения состоит в том, чтобы вы подумали над этим на досуге. Если интересно обсуждать системы, то, наверное, имеет смысл перенести продолжение этого разговора в отдельную тему. То, что я хотел сказать здесь, я уже сказал: «Oberon, в том виде, котором он есть сейчас хорошо реализует принципы структурного программирования, и потому его удобно использовать для написания подпрограмм и модулей. Но он нарушает системные принципы,  правильнее было бы сказать, что не запрещает нарушать системные принципы, не формирует культуру построения систем, как, в свое время, Фортран не запрещал оформлять дополнительные точки входа (entries) в тело подпрограммы, за что его жестко и справедливо критиковали адепты структурного программирования».


№ 4157   19-04-2007 01:42 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4151« (ASU)

И еще... в Вашем решении... Попробуйте изменить логику Server, не останавливая работу системы... Сможете? Нет... Вы получили «неотчуждаемое» решение... то есть, Вы стали рабом (заложником) своего собственного детища... Любое изменение требует привлечения разработчика.

В системах, к разработке которых я когда-то имел отношение (системы управление РВСН - НПО "Импульс"), конечный пользователь никогда, ни при каких обстоятельствах, не имел права (и не имел никакой возможности) менять логику без привлечения разработчиков.  А вот, операторы Чернобыльской АЭС имели, если не право то, по крайней мере, возможность.  Так что, системы бывают разные, соответственно всякие там "возможности" или "невозможности" надо специально продумывать и специально закладывать. Насколько удобны Обероны для разработки систем  со  подобными "возможностями/невозможностями" ? Думаю, что удобны.


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


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

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

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

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

Перейти на конкретную страницу по номеру
  
Время на сайте: 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» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

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