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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


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

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

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

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


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

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

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

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

<<<... | 3976—3967 | 3966—3957 | 3956—3947 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 230


№ 3966   16-04-2007 14:24 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3961« (Mirage)
___________________________

Фолды в среде или директивы компилятору (раз уж говорили тут о препроцессоре) изящно (это про фолды :) ) решают проблему.

Пардон за мою дремучесть, а что есть фолды? Каталоги что ли? Если так, то как насчет рассогласования версий модуля?

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

Интерфейсы по определению не должны "плавать", более того, считается, что на их разработку должно уходить времени почти столько же, сколько на сам модуль (его реализацию). В смысле: продумывать хорошенько надо. А расстановка звездочек и минусиков как-то к этому не располагает. Хочу -- поставлю, хочу -- уберу. Не здорово это как-то.


№ 3965   16-04-2007 14:07 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3962« (Сергей Перовский)
___________________________

>>>А интерфейс может быть ТОЛЬКО абстрактным. Синтаксический минимализм, это конечно приятно, но считать интерфейс частным случаем модуля все таки не стоит.

Пока что не понял этого замечания.
Интерфейс есть не частный случай модуля, а внешнее представление модуля.
Модуль как бы имеет две составляющие: внешнюю (интерфейс) и внутреннюю (реализацию).
Честно говоря, я не очень представляю, как можно говорить об интерфейсе без модуля.
Интерфейс чего?
 AVC


№ 3964   16-04-2007 09:33 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3959« (Руслан Богатырев)
___________________________

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

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

Но отличие Хаскелла от Оберона тут в том, что никаких звёздочек нет, а просто в списке экспорта перечисляется набор экспортируемых сущностей.

И не надо никаких фолдов(?) или директив препроцессора...


№ 3963   16-04-2007 08:47 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3952« (Как слышно? Приём!)
___________________________
>>>Вместо обсуждения предложения создать легкий вьюер составных обероновских
документов
Инициатива наказуема :)
Что там обсуждать - делайте, никто не возражает.
Если люди приходят на базарную площадь, значит у них есть идеи или сомнения, которые хочется обсудить. И пользу они от этого обсуждения получают.
У Райкина когда-то была такая миниатюра:"22 бугая мячик пинают - им нужно лопаты выдать и поставить яму копать".


№ 3962   16-04-2007 08:42 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3954« (Mirage)
___________________________
>>>Модуль может быть абстрактным (как и класс) и не содержать никакой реализации.
А интерфейс может быть ТОЛЬКО абстрактным. Синтаксический минимализм, это конечно приятно, но считать интерфейс частным случаем модуля все таки не стоит.
Иначе получается, то что получается: сначала декларируется явное указание модуля, из которого импортируется сущность, а потом выясняется, что на самом деле это имя интерфейса.
Та же история, что и с объектами: как отдельный раздел типов данных объекты синтаксически не выделяются, но предоставляются все механизмы реализации.


№ 3961   16-04-2007 08:08 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3959« (Руслан Богатырев)
___________________________

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

Фолды в среде или директивы компилятору (раз уж говорили тут о препроцессоре) изящно (это про фолды :) ) решают проблему.


№ 3960   16-04-2007 07:53 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3959« (Руслан Богатырев)
___________________________

Вдогонку предыдущему сообщению. В языке Modula-3 одной реализации модуля на уровне языка может соответствовать несколько интерфейсов. Сколь часто требуется в практике подобная особенность? Ее ведь можно ввести в Оберон/КП, практически не нарушая язык.


№ 3959   16-04-2007 07:30 Ответить на это сообщение Ответить на это сообщение с цитированием
К вопросу об интерфейсах.

При переходе от Модулы-2 к Оберону произошла свертка и смена полярности: DEFINITION-модуль стал производным от MODULE, в котором программист отмечает явным образом (значками экспорта) "протаиваемые" наружу сущности. Поскольку одной реализации (MODULE) соответствует один интерфейс (DEFINITON), то нет смысла давать им разные имена. Говоря "импортируем модуль", мы всегда подразумеваем "импортируем интерфейс" с тем же именем. Именно это, скорее всего, и ввело в заблуждение некоторых участников дискуссии. С другой стороны, трудно себе представить, как можно импортировать то, что не экспортировано, а то, что экспортировано, всегда лежит в интерфейсе (оно и только оно).

Чтобы не было терминологической путаницы, будем считать, что объявлением (declaration) называется полноценное определение сущности, а описанием (definition) -- частичный вариант объявления (в экспортном исполнении). Описания могут быть представлены только в описательных модулях (DEFINITION). В языке Модула-2 DEFINITION-модуль содержал как объявления, так и описания. При этом объявление, сделанное в нем, автоматически было доступно в IMPLEMENTATION-модуле (не требовался "внутренний импорт"). Описание часто использовалось для т.н. скрытых типов (обычно, ссылочных типов), а также для всех без исключения процедур (тела их не могут фигурировать в интерфейсе). В Модуле-2 на уровне IMPLEMENTATION-модулей допускался циклический импорт (поскольку импортировались интерфейсы), тогда как на уровне DEFINITION-модулей цикличность запрещалась. При переходе в Обероне к иной схеме (отказу от явного, "рукотворного" DEFINITION) эти проблемы ушли, а разница между объявлением и описанием многими вообще перестала ощущаться (хотя она сохранилась). Однако, не все так замечательно.

Рассмотрим типичную ситуацию. У нас есть некий модуль M, который находится в стадии доводки. При этом этот модуль экспортирует как доступные клиентам сущности, так и имеет в дополнение к "парадному подъезду" еще и "служебный вход" (например, для целей специальной трассировки). Необходимо сохранять служебные сущности, но при этом время от времени закрывать к ним доступ другим клиентам. В Модуле-2 для этого можно было иметь два интерфейса (в разных файлах -- расширенный и обычный), которые подменялись на уровне конфигурирования системы программирования (напр., в файле проекта). В IMPLEMENTATION-модуле при этом никаких манипуляций делать не надо (только перетранслировать его и всю цепочку зависимости по импорту). В Обероне, строго говоря, надо для этого заниматься перемаркировкой экспорта (то ставим звездочки, то убираем). Не здорово.

Еще о двойственности интерфейсов. Если взглянуть на правила синтаксиса классического Оберона,

ImportList = IMPORT import {"," import} ";" .
Import = ident [":=" ident].

то можно заметить, что теоретически допускается использование объявлений вида

IMPORT A := Str, B := Str;
IMPORT A, B := Str;
IMPORT Str, A, B := Str;


Как я заметил по описанию КП, тот же самый синтаксис используется и в КП. Т.е. можно ставить в соответствие одному физическому имени (справа) интерфейса два логических (слева), причем даже совпадающие с физическим. Одному логическому имени (группе логических имен) ставить в соответствие группу физических имен нельзя. Насколько это поддерживается теми или иными системами программирования Оберонов/КП, надо проверять. Но теоретически такая возможность в язык заложена.

К каким последствиям это может привести?
1. Есть возможность "разрезать" интерфейс в контексте данного модуля-клиента на несколько логических частей. Это позволяет "маркировать" внешние сущности по каким-то признакам (например, процедуры -– по функциональному назначению).
2. Использование в левой части оператора "именной коммутации" физического имени, отличного от значения в правой части, следует рассматривать как  недопустимую практику (желательно, чтобы контролировалась компилятором, если тот может определить наличие интерфейса в своей зоне ответственности).
3. Использование в левой части физического имени, совпадающего с именем в правой части, допустимо. Может быть полезно в качестве "маркировки", при выделении сущностей (скорее всего, процедур и переменных), прошедших тот или иной контроль (физическое имя), от еще не прошедших (логическое имя).
4. Теоретически возникает коллизия: если используется одна и та же сущность в одном модуле-клиенте под разными имена, например, A.Size и B.Size. Если рассматривать это как механизм синонимизации (как обосновывается это в описаниях обоих языков), то коллизии быть не должно -- такое использование допустимо. С другой стороны, может возникнуть иная коллизия -- смысловая (для программиста), поскольку одна и та же внешняя сущность называется по-разному.

О реализациях. Можно ли к одному интерфейсу (DEFINITION) иметь несколько альтернативных реализаций? Да, можно. Это находится в сфере компетентности конфигурирования системы программирования (а также загрузчика).

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


№ 3958   16-04-2007 05:22 Ответить на это сообщение Ответить на это сообщение с цитированием
сообщение от модератора

Флейм будет пресекаться независимо от источника


№ 3957   16-04-2007 04:55 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3952« (Как слышно? Приём!)
___________________________

Ответ на »сообщение 3947« (Владимир Лось)
___________________________
То есть прикажете терпеть словоблудие?
В Обероне как раз технологий то маловато. Всё больше рукоделие предлагается.
Вместо обсуждения предложения создать легкий вьюер составных обероновских
документов, например, или развить инструментальную панель ББ для облегчения
создания интерфейсов, о чём плачет вся молодёжь на сайте metasystem,
что мы лицезреем?

Готовим. И вьювер, и кое-что еще. Скоро будет новый Service-Pack. И новый школьный пакет. И новый ABF. Скоро, уже почти в прокате :-)


<<<... | 3976—3967 | 3966—3957 | 3956—3947 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 230


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

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

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

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

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

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