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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
 
 09:30 Geo
 
 
Во Флориде и в Королевстве сейчас  09:42[Войти] | [Зарегистрироваться]
Обсуждение темы:
Мысли об Обероне

На базарной площади довольно часто можно слышать высказывания об Обероне. Мне кажется, что на базарной площади пора появиться ветке об этой системе и языке, что-то вроде "Мысли об Обероне". Что это такое, перспективы этой системы, что полезного можно извлечь из него для программирования на Дельфи (например) и др.

Ivan

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

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

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


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


Ссылки по теме "Оберон" и "Компонентный паскаль"



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


Смотрите также обсуждения:
Free Pascal, Oberon, BlackBox
  • Разработка препроцессора gpre для delphi\freepascal.
  • Component Pascal и среда разработки BlackBox
  • FreePascal: реальная альтернатива или OpenSource — блажь?

  • <<<... | 3811—3802 | 3801—3792 | 3791—3782 | ...>>>
    Всего сообщений в теме: 4531; страниц: 454; текущая страница: 74


    № 3801   15-12-2005 06:58 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ну это -- fingerprints разные...

    Ага. "Отпечатки пальцев" видимо фиксируют все "прожилки" интерфейса.

    А если мне важно знать дату снятия отпечатка? Или это не фиксируется? А если мне важно знать изменение порядка следования описаний (т.е. они те же, но в другом порядке)? Это контролируется. Вопросы почти праздные, но интересно же...


    № 3800   15-12-2005 06:41 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3799« (Руслан Богатырев)
    ___________________________

    Кстати, насчет амба.

    Провокационный вопрос для знатоков.

    Я работаю с модулем. Транслирую. Что берет компилятор в качестве его интерфейса? Бинарную часть ранее оттранслированного интерфейса или мои нынешние звездочки в исходном тексте? По-разному? Если по-разному, то, значит, он отвергнет мои звездочки, а на каком-таком основании? А если всегда правит бинарный SYM-файл, то как быть другим модулям, которые его импортируют? У них же привязка к нему. Раздельная компиляция.


    Ну это -- fingerprints разные...
     AVC


    № 3799   15-12-2005 06:39 Ответить на это сообщение Ответить на это сообщение с цитированием
    Кстати, насчет амба.

    Провокационный вопрос для знатоков.

    Я работаю с модулем. Транслирую. Что берет компилятор в качестве его интерфейса? Бинарную часть ранее оттранслированного интерфейса или мои нынешние звездочки в исходном тексте? По-разному? Если по-разному, то, значит, он отвергнет мои звездочки, а на каком-таком основании? А если всегда правит бинарный SYM-файл, то как быть другим модулям, которые его импортируют? У них же привязка к нему. Раздельная компиляция.


    № 3798   15-12-2005 06:30 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3796« (Руслан Богатырев)
    ___________________________


    Погодите, а вот если мы в команде работаем. Там надо жестко -- зафиксировал интерфейс -- и ни-ни, менять нельзя. Под интерфейс же могут специальную железяку делать. А тут кто-то дернул что-то в модуле, ткнул новую звездочку и -- амба!


    В том ETH Oberon для того, чтобы изменить интерфейс модуля требуется специальная опция компилятора (\s).
    Так что это не совсем бесконтрольно. :)
    Но мысль -- понятна, спасибо.
     AVC


    № 3797   15-12-2005 06:03 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3792« (Сергей Губанов)
    ___________________________

    2.Как я понял, недостатки модулей Оберона так и не названы, может стоит их назвать?

    Недостаток их в том, что их придумали не в Microsoft.


    Это не недостаток модулей, а недостаток почти всего.


    № 3796   15-12-2005 06:01 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3794« (Takun)
    ___________________________

    Дык это... Если отбросить расширение типа (и рассматривать Оберон как чисто модульный язык), то в нем не поддерживается программирование от интерфейса (модуля). Я не могу задать интерфейс, а затем проверять реализации на соответствие ему.

    Ну наконец-то! Верно.

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

    Что же за недостатки? Рассмотрим пока лишь один, который верно отметили.

    Если с модулями работает один программист (программист-хозяин), то для него не проблема заполучить интерфейс. Нажал кнопку и среда (а может и специальная часть компилятора) извлекает из исходного текста все то, что помечено признаком экспорта (звездочка в Обероне; звездочка и минус в Обероне-2 и Компонентном Паскале).

    Кстати, а что он получит? Текстуальную часть интерфейса, которая аналогична тому, что дается компилятору (ну на самом деле компилятору дается немного больше, но это детали).

    А есть в этой части комментарии? Вопрос. А нужны? А как же, а как, простите, другие со всем этим хозяйством будут разбираться? Надо бы по-культурному -- написать предусловия и постусловия хотя бы словами.

    Ну, выкрутиться можно. В той же ETH Oberon можно писать (** ... *) и такой комментарий автоматически выливается в интерфейс. Ну напридумывали!

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

    А если я хочу там все отформатировать по-красивому, как у людей? Ну, чем богаты. Хотите -- оформляйте.

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

    Погодите, а вот если мы в команде работаем. Там надо жестко -- зафиксировал интерфейс -- и ни-ни, менять нельзя. Под интерфейс же могут специальную железяку делать. А тут кто-то дернул что-то в модуле, ткнул новую звездочку и -- амба!

    Извиняйте, в Modula-2 таких проблем не было. Там интерфейс отдельно. И транслируется отдельно, и оформляй, как хочешь, и контролируется соответствие вплоть до битика причем и при раздельной компиляции, и при загрузке модулей.

    Да, но там были другие проблемы...


    № 3795   15-12-2005 05:43 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3787« (iZEN)
    Мне понравилась ситуация в конексте описания принципа Открыт-Закрыт, где показан явный провал чистого (без ООП) модульного проектирования системы на примере модификации "закрытого" модуля и вынужденной лавинообразной переделки всех клиентских модулей, использующих его.

    Наглое враньё!

    Расширяемые модульные системы удовлетворяют Open/Close-принципу (открытость для расширения закрытость для модификации) просто напросто по своему определению! Модули (бинарные) - всегда закрыты для модификации. Расширяемая модульная система - всегда открыта для расширения (другими модулями).

    Есть система. Нужно её расширить? Прекрасно, (динамически) меняем в ней модули на другие. Все дела.

    Что касается "вынужденной лавинообразной переделки всех клиентских модулей", тоже враньё. Читайте диссертацию:
    "Separate Compilation and Module Extension" Regis Crelier (th10650)


    № 3794   15-12-2005 05:38 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3776« (Руслан Богатырев)
    ___________________________

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

    Кстати, небольшой вопрос знатокам: в чем заключается явный недостаток языков Оберон, Оберон-2 и Компонентный Паскаль в отношении поддержки модульного программирования (общий для всех этих языков)?

    Отсутствием DEFINITION (и возможности его реалзиации) на уровне языка?

    Так DEFINITION во всех трех языках автоматически можно получить из текста модуля. А что значит реализация DEFINITION? MODULE реализует тот интерфейс, который задается спецификаторами экспорта (звездочки и минусы). Что же тут не так? Точнее, в чем же недостаток?

    Дык это... Если отбросить расширение типа (и рассматривать Оберон как чисто модульный язык), то в нем не поддерживается программирование от интерфейса (модуля). Я не могу задать интерфейс, а затем проверять реализации на соответствие ему.


    № 3793   15-12-2005 05:38 Ответить на это сообщение Ответить на это сообщение с цитированием
    Итак, капсула и интерфейс.

    Что помещают в капсулу? Да по-разному. А что хотелось бы? А все, что можно поместить. Хорошо. Смотрим, что есть у нас из сущностей: константы, переменные, типы, процедуры, классы. Ничего не забыли? Вроде бы нет. А, модули! Ну ничего, пока пусть полежат в сторонке.

    Значит, если в капсулу все это можно поместить и снаружи сделать интерфейс (описания сущностей и средств доступа), то должно быть неплохо.

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

    Ладно, берем тип. У него есть имя. Он определяет набор данных определенной структуры. Если структуру скрываем – все, получили абстрактный тип данных (АТД). Тип, как правило, не бывает сам по себе – должны быть присущие ему (штатные) операции работы с ним. Нештатные операции (манипулирование данными этого типа помимо его определения) рассматривать для простоты не будем. Где у него интерфейс? Как минимум, это его имя. Ничего себе, хорош интерфейс. А еще? А еще заголовки штатных для него процедур. А еще? Хватит. Структуру он показывать наружу не будет. Ну если только ее кусочек. Ага, значит, в принципе к интерфейсу типа можно отнести и часть его внутренней структуры? Так, а что с капсулой, что в тип можно спрятать? Так почти все – константы, переменные, процедуры. А классы? Ну нет, классы не надо. А типы? Если только служебные для него, а такие, чтобы и другие снаружи могли попользоваться, нельзя. Хорошо, значит АТД может быть капсулой с интерфейсом? Получается, может.

    Так, теперь берем класс. Да что тут обсуждать – посмотрите на Java. Капсула есть, интерфейс есть, внутри все есть. А новый тип внутри есть? А модуль внутри есть? А другой класс внутри есть? Озадачили, надо подумать. Ну, тогда, наверное, не все. Но ведь капсула и интерфейс, чего еще надо?

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


    № 3792   15-12-2005 05:36 Ответить на это сообщение Ответить на это сообщение с цитированием
    2.Как я понял, недостатки модулей Оберона так и не названы, может стоит их назвать?

    Недостаток их в том, что их придумали не в Microsoft.


    <<<... | 3811—3802 | 3801—3792 | 3791—3782 | ...>>>
    Всего сообщений в теме: 4531; страниц: 454; текущая страница: 74




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

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

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

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

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