Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 3986 16-04-2007 22:31 | |
Ответ на »сообщение 3965« (AVC)
___________________________
Интерфейс есть не частный случай модуля, а внешнее представление модуля.
О! Начинаем... докапываться до сути... Несмотря на искреннее уважение и благодарность... согласиться с Вами не могу... ни на йоту.
Модуль как бы имеет две составляющие: внешнюю (интерфейс) и внутреннюю (реализацию).
Честно говоря, я не очень представляю, как можно говорить об интерфейсе без модуля.
Интерфейс чего?
Об интерфейсе надо говорить именно без модуля!.. Или, говоря иначе, интерфейс ничего общего с модулем не имеет - это конструкция совершенно иного порядка.
С Вашего позволения, более развернуто, я напишу при ответе на Ваше следующее сообщение.
№ 3985 16-04-2007 22:25 | |
Ответ на »сообщение 3962« (Сергей Перовский)
___________________________
интерфейс может быть ТОЛЬКО абстрактным. Синтаксический минимализм, это конечно приятно, но считать интерфейс частным случаем модуля все таки не стоит.
Поддерживаю! На все 100% :)
№ 3984 16-04-2007 22:23 | |
Ответ на »сообщение 3954« (Mirage)
___________________________
Судя по всему вы слегка не поняли что собственно представляет собой (или может представлять) модуль. Это ведь самый что ни на есть интерфейс.
Не исключено, что я «слегка не понимаю», что представляет собой модуль... Но совершенно точно, что термин «интерфейс» мы с Вами понимаем совершенно различно... :)
Чуть позже я поясню...
Кстати, если квалификация модуля противоречит теории систем, то квалификация поля классом тоже противоречит.;)
Нет, не противоречит.
№ 3983 16-04-2007 18:50 | |
Ответ на »сообщение 3980« (AVC)
___________________________
>>>Тем интереснее будет сопоставить дельфийские и обероновские модули, чтобы понять, как такое может быть: модули в языке есть, но они "на вторых ролях".
Прочитайте указанную статью Богатырева, там все достаточно точно разобрано. Дельфийские и обероновские модули абсолютно разные вещи. Просто некоторые сторонники Оберона используют прием ASU: модуль, это то, что в Обероне, а то, что раньше называли модулем, это неправильно :)
Все виды модульности в Обероне слиты в один: "Оберон-модуль является унифицированной единицей компиляции, компоновки, загрузки и замены"(с) Руслан Богатырев.
В некоторых задачах это удобно. Но, вообще говоря, разбивка на единицы компиляции, компоновки и загрузки может вестись из различных соображений и "принудительная уравниловка" меня не слишком привлекает.
В Дельфи program и library создают модули компоновки и загрузки, а unit-модули трансляции. На мой взгляд это удобнее.
Тут опять имеет место синтаксический минимализм. Ничего не имею против этого подхода, но IMHO слишком часто в случае с Обероном синтаксический минимализм балансирует на грани разумного.
Насчет того, что модули в Дельфи на вторых ролях я не соглашусь, это очень важный и полезный инструмент.
№ 3982 16-04-2007 18:19 | |
Ответ на »сообщение 3965« (AVC)
___________________________
>>>Интерфейс есть не частный случай модуля, а внешнее представление модуля.
Я уже много раз указывал на СОМ технологию - там интерфейс это отдельная сущность, регистрируемая в ОС. Если какая нибудь задача запрашивает работу с некотором интерфейсом, система ищет, кто зарегестрирован, как исполнитель данного интерфейса. Таким образом мы получаем гораздо более слабые связи между текстами модулей. Поскольку интерфейсы регистрируются и вызываются при помощи GUID никакой конфликт имен невозможен.
К сожалению, СОМ интерфейсы могут включать только процедуры. Но к рассматриваемым механизмам это отношения не имеет.
№ 3981 16-04-2007 17:48 | |
ответ на »сообщение 3980« (AVC)
Лично для меня знакомство с "настоящими делфийскими модулями" произошло следующим образом: как-то мы решили на скорую руку собрать приложение из отдельных exe-х, "по рабоче-крестьянски", с помощью WinExec. Через некоторое время мы "вдруг" заметили, это наше "архитектурное" решение наиболее устойчиво, благополучно переходит из проекта в проект, очень удобно с точки зрения модификаций и т.д. и т.п. Правда пришлось немного поизощряться с организацией взаимодествия наших "модулей". В частности для "тонкого" взаимодействия используем обмен сообщениями (WMCopyData). В общем мы поняли, что такое настоящие модули и чем они отличаются от unit-ов.
№ 3980 16-04-2007 16:49 | |
Ответ на »сообщение 3979« (Илья Ермаков)
___________________________
>>>Могу сказать точно, что работа в Дельфи и чтение различной литературы по ней для меня ничуть не способствовало правильному пониманию сути модулей. Модули в Дельфи повсеместно "на вторых ролях": ну, есть - и ладно. Программируя несколько лет на Дельфи, я так и не прочувствовал модульности.
Это очень интересный факт, а для меня так прямо -- неожиданный!
Я почему-то предполагал, что "дельфийцы" в более выгодном (по сравнению со мной) положении для освоения Оберона.
Тем интереснее будет сопоставить дельфийские и обероновские модули, чтобы понять, как такое может быть: модули в языке есть, но они "на вторых ролях".
№ 3979 16-04-2007 16:30 | |
Ответ на »сообщение 3977« (AVC)
___________________________
Ответ на »сообщение 3975« (Руслан Богатырев)
___________________________
Возможно, стоит провести опрос среди самих "оберонщиков": как именно они усваивали понятие модуля? Помогало ли им знание родственных конструкций других языков (например, дельфийских модулей)?
Т.е. осознать собственный путь к модульности и извлечь отсюда уроки.
Могу сказать точно, что работа в Дельфи и чтение различной литературы по ней для меня ничуть не способствовало правильному пониманию сути модулей. Модули в Дельфи повсеместно "на вторых ролях": ну, есть - и ладно. Программируя несколько лет на Дельфи, я так и не прочувствовал модульности. Поэтому после перехода на С++ даже воевал на дельфийских сайтах, доказывая, что "в С++ модули есть, и более гибкие, чем в Дельфи - хотите инклюд, хотите наймспэйс..."
Знакомство с модульностью началось позже, с языка Ada. Концепция пакетов, раздельной компиляции, сокрытия "внутренностей", разложенность по полочкам, конструктивная продуманность восхитили. Ну а потом "случился" Оберон :-)
№ 3978 16-04-2007 16:24 | |
Ответ на »сообщение 3977« (AVC)
___________________________
Т.к. мы находимся на дельфийском сайте, отталкиваться от модулей Delphi вполне логично, т.к. многим они знакомы.
Тогда было бы неплохо, если кто-нибудь из спецов по Delphi глянул мое старое сравнение: http://www.europrog.ru/qa261005.html
Я большей частью опирался на описания, поэтому мог вполне что-то напутать, забыть, упустить. После сверки можно будет набросать коротенькую (экспресс-версию на 1-2 абзаца), с различиями, что называется, на пальцах.
№ 3977 16-04-2007 16:05 | |
Ответ на »сообщение 3975« (Руслан Богатырев)
___________________________
>>>А такой ли модуль Оберона уникальный, что его устройство непонятно? Может, пояснять на примере чего-то известного, например, модулей Delphi?
Вопрос интересный.
Т.к. мы находимся на дельфийском сайте, отталкиваться от модулей Delphi вполне логично, т.к. многим они знакомы.
Мне же пришлось усваивать это понятие практически с нуля, т.к. я почти всю жизнь пишу на Си/Си++.
Естественно, что в Обероне меня привлекли сначала не модули, а то, что info21 удачно назвал "герметичностью" системы типов. Просто я настрадался в Си с противоположностью этой "герметичности". Так что откликнулся на type safety и сборку мусора весьма живо.
А вот модули поначалу я не особенно воспринимал (ну есть, и хорошо).
Проникся позже, и теперь обратная картина: уже думать не могу о "немодульных" решениях.
Возможно, стоит провести опрос среди самих "оберонщиков": как именно они усваивали понятие модуля? Помогало ли им знание родственных конструкций других языков (например, дельфийских модулей)?
Т.е. осознать собственный путь к модульности и извлечь отсюда уроки.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|