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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


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

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

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

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


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

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

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

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

<<<... | 4296—4287 | 4286—4277 | 4276—4267 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 198


№ 4286   22-04-2007 06:04 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4274« (ASU)
___________________________


Контракт с кем? Контракт (договор) предусматривает более одной стороны...

Это открытый контракт, подписанный с одной стороны (исполнителя).
С другой стороны (Заказчика) его может подписать любой, готовый выполнить объявленные в контракте условия


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

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

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

n:=1
while n<2 do
  n:=n+0
end


Случай конешно вырожденный, но блок-схему нарисовать проблем нет.
И если это не алгоритм то что?


№ 4284   22-04-2007 05:49 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4282« (Руслан Богатырев)
___________________________

Другими словами, язык Оберон/КП не предусматривает на уровне компилятора контроль соответствия разных версий реализации тому или иному интерфейсу.

Кстати, в XDS-реализации Оберона-2 (он в смысле экспорта-импорта от классического Оберона не отличается) сохранена схема Модулы-2. Это удобно еще и потому, что позволяет использовать оба языка одновременно (Модула-2 лучше Оберона подходит для низкоуровневых вещей).


№ 4283   22-04-2007 05:37 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4259« (AVC)
___________________________
Мультиязычность систем может иметь один конкретный недостаток: недостаток надежности.
Хм?.. Вообще-то... строго наоборот... Возможно, Вы рассуждаете с позиций использования языков на одном уровне. Получается мешанина, которую трудно поддерживать, а не то что развивать. И надежность у такой конструкции... действительно вызывает большие сомнения. Но, я же говорил о том, что каждый язык (средство) должны использоваться на том уровне, где они максимально эффективны (и для написания, и для сопровождения, и для развития). Вы же не станете отрицать, что есть области, где функциональные языки или языки логического программирования позволяют проще и красивее решать задачи, по сравнению императивными языками. И если на каждом уровне вместо использования ложка-грабли-молотка (универсального инструмента) применять адекватные средства разработки, то надежность от этого только выиграет. Согласны?

В Обероне архитектура призвана поддерживать расширяемость системы (в принципе -- неограниченную).
Любимое Вами "буйство жизни". :)

Нет... Это не любимое мной... Мы слишком различно (как я понимаю) воспринимаем мир... Посмотрите за окно. Что Вы видите? Солнце светит, белые облака на голубом небе, девушки удивительно красивые... «Буйство жизни», одним словом... В Обероне «буйство жизни» - это делай (на уровне модулей) все что хочешь... захотел импортировать – импортируй, захотел экспортировать – экспортируй (вдруг кому-то зачем-то сгодится!)... Анархия... За моим окном... все не так... Все, что там есть – электроны, протоны и нейтроны... все остальное величайшее искусство (многоуровневой) композиции основанное на простых, но строгих законах. И свою задачу мы, наверное, видим различно... для Вас (надеюсь я ошибаюсь) важно повторить многообразие, для меня... освоить искусство композиции... :)

Новые модули добавляются поверх старых, а старые могут расширить свой экспорт.
Вот... вот...

Цель была не в том, чтобы создать один конкретный программный комплекс, а в том, чтобы создать систему, способную к расширению.
... то есть, постепенному добавлению все новых элементов... нет, красивых девушек... так не... создать. IMHO. :)

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

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


№ 4282   22-04-2007 05:33 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4279« (Антон Григорьев)
___________________________

Понятно, что при подмене модуля линкер проверит соответствие модуля B интерфейсу A и, если обнаружится несоответствие, выдаст ошибку. Но можно ли эту проверку осуществить на этапе компиляции?

В этом и есть отличие схем экспорта-импорта Модулы-2 и Оберона. В Модуле-2 интерфейс (он называется DEFINITION MODULE) -- это полностью самостоятельная вещь, создаваемая программистом НЕЗАВИСИМО от реализации (IMPLEMENTATION MODULE). В Обероне произошла "свертка", которая решила одни проблемы, но за счет порождения других (так обычно и происходит).

Подробно я разбирал этот вопрос здесь:
»сообщение 3788«
»сообщение 3789«
»сообщение 3800«

Другими словами, язык Оберон/КП не предусматривает на уровне компилятора контроль соответствия разных версий реализации тому или иному интерфейсу. Это можно сделать лишь косвенно, что не есть хорошо. Эту проблему можно решить относительно безболезненно (имея в виду схему Модулы-2 и контроль со стороны верификатора).


№ 4281   22-04-2007 05:20 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4280« (Сергей Перовский)
___________________________

Каждый участник ДОЛЖЕН именовать свое творение по своему - иначе очень сложно разбираться в вариантах.

Он должен свое творение положить в конвертик, на котором проставляется шифр (или реальное имя) идентифицирующее участника конкурса.

Различие реализаций под один интерфейс -- это версионирование. Безотносительно того, делает это один и тот же разработчик (последовательно) или разные группы разработчиков (асинхронно).

Поэтому НЕ ДАВАТЬ использовать файловую систему для различия реализаций не слишком удачная идея.

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


№ 4280   22-04-2007 05:14 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4273« (Руслан Богатырев)
___________________________
>>>По-другому названный модуль -- это следствие двух вещей:
Или двадцати двух :)
Например я описал интерфейс и объявил конкурс на его реализацию :)
Каждый участник ДОЛЖЕН именовать свое творение по своему - иначе очень сложно разбираться в вариантах. Тестирующая программа должна подключать по очереди все реализации и проводить их проверку.
>>>разработчику лень использовать средства управления версиями и он для имитации этого применяет файловую систему.
Фраза построена осуждающе, но средства управления версиями далеко не всегда предпочтительнее файловой системы-- это вопрос желания/хотения и конкретной ситуации.
Поэтому НЕ ДАВАТЬ использовать файловую систему для различия реализаций не слишком удачная идея.


№ 4279   22-04-2007 05:11 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4273« (Руслан Богатырев)
___________________________

Модульный подход, реализованный в языке Оберон/КП, предсматривает обращение из модуля к интерфейсу (давайте это где-нибудь напишем большими буквами и повесим плакат). Реализации Оберона/КП (Oberon System, BlackBox) наглядно демонстрируют, что добиться динамической подмены реализации под заданный и зафиксированный интерфейс, это не только не проблема -- это основа упомянутых расширяемых систем. Но для этого нет надобности вводить динамику соответствия "интерфейс-реализация" на уровне языка. Достаточно их просто разделить, что и сделано в языке (DEFINITION -- отдельно, MODULE -- отдельно).

Когда есть интерфейс и реализация, возможны четыре варианта отношений:
1. один-к-одному (один интерфейс -- одна реализация)
2. один-ко-многим
3. многие-к-одному
4. многие-ко-многим

Вирт (Модула-2, Оберон) пошел по первому пути. Этот путь позволяет называть интерфейс так же, как и реализацию (одинаковым именем), но не запрещает подменять реализации в динамике выполнения.


В связи с этим возникает такой вопрос. Пусть у нас есть некоторый модуль A и созданный на его основе интерфейс (он же - DEFINITION). Теперь мы хотим создать модуль B, который будет реализовывать такой же интерфейс, что и A. Понятно, что при подмене модуля линкер проверит соответствие модуля B интерфейсу A и, если обнаружится несоответствие, выдаст ошибку. Но можно ли эту проверку осуществить на этапе компиляции? Как-то указать компилятору, что модуль B должен соответствовать интерфейсу A, и если обнаруживается несоответствие, чтобы этот модуль просто не компилировался. В описании Оберона я таких возможностей не увидел, а без них интерфейс не может считаться по-настоящему отчуждаемым.


№ 4278   22-04-2007 05:08 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4253« (Takun)
___________________________
Возьмем в качестве учебного примера Интернет (раз уж компилятор не погодился ;-) ). Уровни у него есть (если исходить из модели в виде стека протоколов). Объектов полно, слабых связей тоже. Практически все можно выключить или заменить без потери его системности.
Надеюсь никто не скажет, что Интернет маленькая система?
Спрашивается, в каком месте у него над-уровень?

Хороший вопрос... Посмотрите стандарт OSI... :)

Логично предположить, что сверху. Но среди многочисленных прикладных служб, как то: Web, FTP, Email, Emule, DNS, Usenet и т.п., и т.д. я не вижу ничего, что бы являлось для Интернета определяющим. Да, без DNS было бы тяжко, но если заменить его альтернативным решением, то Интернет Интернетом быть не перестанет.
А Вы не припомните, кто инициировал запрос о том, что «управление Интернетом» не плохо было бы передать в ведение международной организации... Чем все это закончилось и почему... Теперь «над-уровень» стал понятнее?..

1) Логика системы сосредоточена не в над-уровне, а в связующем уровне, в характеристиках связей стистемы.
Логика системы... Логика системы присутствует на каждом из уровней... И каждый уровень... заглядывая вверх, говорит: «Вот она... какая Система!»... И только самый верхний уровень, посматривая вниз... понимает, что система – это все это сооружение вместе с ним... родимым.

2) Логика системы определяет лишь некоторые свойства системы (определяет некоторый класс систем?).
Правильно, но не совсем точно... Свойства системы – это проекция интерфейса более высокого (над-системного) уровня на данную сущность. Свойств «вообще» не бывает, свойство – это результат взаимодействия. Так вот, (в чем же неточность)... над-система определяет «интерфейс», которому должна соответствовать система, вместо со своей логикой.


№ 4277   22-04-2007 04:55 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4276« (Илья Ермаков)
___________________________

Хорошо :-) Не контракт. Бланк контракта, который модуль затем подписывает с каждым, кто хочет его использовать :-)

Публичная оферта.


<<<... | 4296—4287 | 4286—4277 | 4276—4267 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 198


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

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

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

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

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

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