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

Здесь некоторое недоумение вызывает позиция Н.Вирта, который в недавно опубликованном интервью [Вирт, 1998] заявил, что «расширяемое программирование подразумевает возможность добавления модуля без какого-либо изменения существующих модулей — они не должны даже перекомпилироваться». С первой половиной утверждения (отсутствие изменений существующих модулей) можно уверенно согласиться, но для чего понадобилось безусловно исключить трансляцию из процесса подключения нового модуля — не совсем понятно. Похоже, неявная отправная точка последнего тезиса состояла в том, что Н.Вирт видит подключаемый модуль исключительно в образе модуля трансляции.

Эту мысль Вирт высказал еще раньше. Думаю, полезно восстановить контекст, в котором она была высказана. В разделе 12.4 (Objects and modules) книги Рейзера и Вирта "Programming in Oberon" есть такие слова:

Здесь важно отметить вот какие моменты.

1. На мой взгляд, перевод термина extensible programming как "расширяемое программирование" (что сделал переводчик в журнале "Открытые системы") не совсем удачный. Вирт подразумевает применение такого программирования, которое расширяет системы. Т.е. действие направлено на системы, а не на программирование. Иными словами, лучше применять перевод "расширяющее программирование".

2. Книга Рейзера и Вирта вышла в 1992 г. В плане разъяснения взглядов Вирта более интересна его основополагающая работа Type Extensions. Она была направлена в редакцию журнала ACM Transactions on Programming Languages and Systems в феврале 1987 г., а вышла в апреле 1988 г.

http://www.oberon2005.ru/paper/nw1988.pdf

Некоторые выдержки из нее:

New client modules with new extensions may be added to a system at any time without affecting the base module or other client modules or even
requiring their recompilation. This clearly contrasts with the notion of the abstract data type in which all applicable operators are supposed to be defined together with the data type.

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

Другая выдержка:

Modern software development tools are designed for the construction of extensible systems. Extensibility is the cornerstone for system development, for it allows us to build new systems on the basis of existing ones and to avoid starting each new endeavor from scratch. In fact, programming is extending a given system.

The traditional facility that mirrors this concept is the module-also called package-which is a collection of data definitions and procedures that can be linked to other modules by an appropriate linker or loader. Modern large systems consist, without exception, of entire hierarchies of such modules. This notion has been adopted successfully by modern programming languages, such as Mesa [4], Modula-2 [8], and Ada [5], with the crucial property that consistency of interfaces be verified upon compilation of the source text instead of by the linking process. An enormous number of calamitous pitfalls, which constituted a genuine impediment to the construction of extensible systems, have thereby been eliminated.
The essential ingredient of these systems is that a new module can be developed and changed without the need for recompilation of the modules on
whose resources it rests. It was made possible by the textual separation of a module description into a definition and an implementation part, where the former specifies the interface.

Современные средства разработки ПО проектировались для создания расширяемых систем. Расширяемость (extensibility) является краеугольным камнем в области разработки систем; она позволяет нам строить новые системы на основе существующих и избегать необходимости начинать новый проект с нуля. На самом деле, программирование расширяет заданную систему.

Традиционным средством, которое отражает эту концепцию, служит модуль (module), который называют еще пакетом (package). Он представляет собой набор описаний данных, а также набор процедур, которые могут быть связаны с другими модулями с помощью компоновщика или загрузчика. Современные большие системы состоят (без каких бы то ни было исключений) из целых иерархий таких модулей. Эта концепция нашла свое успешное воплощение в таких языках, как Mesa, Modula-2, а также Ada, с той ключевой особенностью, что целостность интерфейсов может быть гарантирована (верифицирована) при компиляции исходных текстов, а не на этапе компоновки (linking).  Тем самым, может быть устранено огромное число злополучных ошибок, которые служат настоящим барьером на пути построения расширяемых систем. Существенным моментом для этих систем является то, что можно разработать новый модуль и изменять его без необходимости  перекомпиляции тех модулей, на возможности которых он опирается. Этого удалось добиться за счет объявления (description) модуля путем текстуального разделения на описательную (definition) и исполнительную (implementation) части.

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

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

Вы серьёзно? А как же Java? Там вроде бы нет никаких *.dll. Там всё -- *.class. В Delphi тоже есть механизм пакетов, там -- *.dpk. Никаких обёрток. Но дело в том, что там требуется своя среда выполнения (прослойка между Windows и приложением). Если я всё правильно понимаю, в BlackBox'е такая же система. ТАк, вот... Пожалуйста, поправьте, если ошибаюсь.

P.S.
Я обеими руками за классы. Аргументация следующая:

И еще одна цитата, с Вашего позволения...

»сообщение 3834« (iZEN)
___________________________
В современной Java (Java2) возможно создание четырёх вложенных (nested) классов. Их виды:
* класс-член (nonstatic member class)
* статический класс (static member class)
* анонимный класс (anonymous class)
* локальный класс (local class)
Каждый из них наделён определёнными правами доступа к другим членам (даже к закрытым) класса, в котором они определяются.

С позиции Oberon - минимализма явный перебор! :)
Это как-же при этом раздуется синтаксис?!?!?
Если вся эта четверка присутствует в одном классе, для его реализации как нельзя лучше подошел-бы Oberon-модуль. (ИМХО)

1) Концепция модуля базируется на концепции абстрактного типа данных. Если мы хотим использовать модуль, мы должны объявить в модуле-клиенте переменную экспортируемого модулем-сервером типа, а потом использовать операции над этой переменной, экспортируемые модулем-сервером, каждый раз передавая в операцию объявленную переменную как параметр. Такой подход отражает машинную точку зрения (ведь и при использовании классов код операций размещается в памяти один раз, но там, создавая экземпляр мы в нагрузку к данным получаем неотделимые (для программиста) от экземпляра операции), но несколько далёк от человеческого восприятия. Приведу пример. Использование модулей аналогично следующей ситуации: мы покупаем в магазине торт, а потом, если нам что-нибудь потребовалось произвести с ним некоторые операции (разрезать, например), несём его обратно в магазин, чтобы там с тортом сделали всё, что нам нужно. В случае с классами мы просто покупаем торт, а операции с ним совершаем сами (точнее торт осуществляет операции над собой :)), мы лишь должны инициировать действие, т.е., например,  взять нож и начать резать, а как это действие будет осуществлено, решит наш конкретный торт; в магазин каждый раз бегать уже не надо. Пример достаточно условен и, возможно, преувеличивает различие между подходами, но, тем не менее...

Я с теорией ООП вообще-то знаком :)
А процедур связанных с типом (Oberon-2) в этом случае не достаточно?

3)Концепция интерфейсов. Примерно в том виде, в котором они существуют в COM, а точнее в Delphi'йской реализации COM. (Я имею в виду наличие в языке предложения "класс (или, если угодно, модуль) реализует интерфейс"; т.е. представление интерфейсов как отдельных сущностей, а не производных реализации класса (модуля).) В случае с модулями (в том же Oberon'е) использование интерфейсов в таком виде вряд ли возможно.

А если через абстрактные типы?
Немножко повторюсь...
В диссертации Питера Мюллера http://oberon2005.ru/paper/eth14755.pdf есть раздел 3.6 Plugin Modules and Objects.
Там изложена концеция создания драйверов устройств путем создания абстрактного интерфейса устройства interface module...
Целая ОС на этом работает. Bluebottle называется. А что такое COM?
Шутка :)

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

Я за модули - однозначно!
Аргументировать пожалуй не получится, но *.dll это просто маразм!

Ой, не спешите. Любая крайность в таких делах вряд ли может приветствоваться.

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

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

Мои "интересы" лежат в области среднего образования и на "стыке" между средним и высшим. Поэтому мне трудно делать оценки для других предметных областей. Но, тем не менее, ряд возможных областей для Оберонов могу выделить.

1) Первое. Это, конечно, сфера образования, прежде всего среднего. Здесь Оберонам на данный момент практически нет конкуренции.

Да, это очень перспективная ниша для языков малого Оберон-семейства (Оберон, Оберон-2, Компонентный Паскаль). Другое дело, преподавателю (на мой взгляд) важно понимать, чем отличаются друг от друга языки этой тройки. Я очень сильно сомневаюсь, что в школе настоятельно требуется разбирать вопросы программирования в большом, а также ООП с использованием модификаторов ABSTRACT, LIMITED и т.п. Т.е. речь можно вести об уровне языков Оберон или Оберон-2. Не выше.

Если в качестве основной инструментальной среды и среды выполнения выбирается BlackBox, который совмещает в себе эти две разных ипостаси, то придется работать с Компонентным Паскалем, усекая его до возможностей Оберона(-2). Если понадобится преподносить концепцию расширения типа, то придется использовать модификатор EXTENSIBLE и переворачивать с ног на голову идею расширения -- в Обероне запись расширяется по умолчанию и не надо задумываться о возможности последующего расширения, в КП она по умолчанию НЕ РАСШИРЯЕТСЯ. Это принципиальное отличие двух этих языков.

2) Вторая ниша. Думаю, что это задачи, где удельный вес и роль интерфейса минимальны, а роль алгоритма максимальна.

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

3) Третья ниша. Здесь я не специалист, пусть меня поправят профи, но все-таки. Любые системы, где безопасность программирования стоит на 1 месте среди прочих плюсов языка. Что мы здесь имеем на данное время: Ada 95 и Модула 2. С Адой трудно тягаться - в ней параллельное программирование "зашито". Но Модулу, вроде бы, Обероны могут заменить в полном объеме.

Это более спорный момент. Оберон в действительности не может быть отнесен к языкам системного программирования, в отличие от Modula-2. В этом плане связка Modula-2 и Оберон-2 в той же системе XDS работает достаточно хорошо и органично. Одна из проблем Оберона, которую признает и Вирт, состоит в том, что, например, в языке несбалансированы базовые типы данных. Сейчас Вирт считает, что тип INTEGER, напр., должен представлять 32-разрядные целые числа, а типы SHORTINT и LONGINT быть его синонимами. О чем это говорит? О том, что Оберон должен еще дальше уходить от машинного представления не только на уровне работы с адресами, но и в плане базовых типов, таких как INTEGER и REAL. Он не должен быть языком системного программирования. Его диалекты и производные языки -- это отдельный разговор.

4) Четвертое. "Непрофессиональное программирование" (название, конечно, условное).
О чем речь? Ну, конечно, не о тех пользователях, которые вообще не могут программировать, кроме как в Word'e :). О тех, которые могут, но которым не нужно делать промышленный проект.

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

Для такого применения языки малого Оберон-семейства -- вполне подходящий выбор.

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

Ответ на »сообщение 3906« (Владимир Лось)
___________________________


Владимир, угадайте с трех раз из какого языка были произведены заимствования в Компонентном Паскале при переходе к нему от Оберона(-2).
А чё тут угадывать? :о) Они сами писали, что набор и размерности типы в КП сделаны для совместимости с Явой...
Речь-то идёт о том, что народ просто плохо информирован, не интересуется, а если ему начинают говорить о чём-то то большинство ведёт себя, как король из "Обыкновенного чуда", когда придворные пытались ему расскзать о проделках плута-церемониймейстера...

Ну если бы дело было только в базовых типах Компонентного Паскаля... А модификаторы ООП (ABSTRACT, EXTENSIBLE, LIMITED и др.), которые, собственно, и определяют лицо этого языка...

Тут ходила информация о том, что проф. Гуткнехт первым разрушил совместимость с Обероном -- вы ведь давно следите за направлением Active Oberon, включая Lightning Oberon. Не подскажете, в каком году появился диалект Оберона за подписью Гуткнехта?

Компонентный Паскаль Куно Пфистера и Клеменса Шиперски ведет отсчет от 1997 г.

Ответ на »сообщение 3892« (Руслан Богатырев)
___________________________
Владимир, угадайте с трех раз из какого языка были произведены заимствования в Компонентном Паскале при переходе к нему от Оберона(-2).
А чё тут угадывать? :о) Они сами писали, что набор и размерности типы в КП сделаны для совместимости с Явой...
Речь-то идёт о том, что народ просто плохо информирован, не интересуется, а если ему начинают говорить о чём-то то большинство ведёт себя, как король из "Обыкновенного чуда", когда придворные пытались ему расскзать о проделках плута-церемониймейстера...

Ответ на »сообщение 3897« (Руслан Богатырев)
___________________________

"Слова, слова, слова". (с) Уильям наш Шекспир.

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

В диссертации Питера Мюллера http://oberon2005.ru/paper/eth14755.pdf есть раздел 3.6 Plugin Modules and Objects.
Там изложена концеция создания драйверов устройств путем создания абстрактного интерфейса устройства interface module, объекта реестра плагинов plugin registry object, и набора плагинов plugin modules, соответствующих конкретным устройствам. Плагины при этом могут подключаться динамически plugged in dynamically.

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

Приветствую участников дискуссии!

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


Я за модули - однозначно!
Аргументировать пожалуй не получится, но *.dll это просто маразм!
Осбенно процесс написания на них wrapper'ов на мегабайты... :)))
А класс нужно в чем-то хранить.
Все говорят классы, классы... А как они представлены физически - *.dll. Спасибо. Сыты этим  ... погорло.


Вы серьёзно? А как же Java? Там вроде бы нет никаких *.dll. Там всё -- *.class. В Delphi тоже есть механизм пакетов, там -- *.dpk. Никаких обёрток. Но дело в том, что там требуется своя среда выполнения (прослойка между Windows и приложением). Если я всё правильно понимаю, в BlackBox'е такая же система. ТАк, вот... Пожалуйста, поправьте, если ошибаюсь.

P.S.
Я обеими руками за классы. Аргументация следующая:

1) Концепция модуля базируется на концепции абстрактного типа данных. Если мы хотим использовать модуль, мы должны объявить в модуле-клиенте переменную экспортируемого модулем-сервером типа, а потом использовать операции над этой переменной, экспортируемые модулем-сервером, каждый раз передавая в операцию объявленную переменную как параметр. Такой подход отражает машинную точку зрения (ведь и при использовании классов код операций размещается в памяти один раз, но там, создавая экземпляр мы в нагрузку к данным получаем неотделимые (для программиста) от экземпляра операции), но несколько далёк от человеческого восприятия. Приведу пример. Использование модулей аналогично следующей ситуации: мы покупаем в магазине торт, а потом, если нам что-нибудь потребовалось произвести с ним некоторые операции (разрезать, например), несём его обратно в магазин, чтобы там с тортом сделали всё, что нам нужно. В случае с классами мы просто покупаем торт, а операции с ним совершаем сами (точнее торт осуществляет операции над собой :)), мы лишь должны инициировать действие, т.е., например,  взять нож и начать резать, а как это действие будет осуществлено, решит наш конкретный торт; в магазин каждый раз бегать уже не надо. Пример достаточно условен и, возможно, преувеличивает различие между подходами, но, тем не менее...

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

3)Концепция интерфейсов. Примерно в том виде, в котором они существуют в COM, а точнее в Delphi'йской реализации COM. (Я имею в виду наличие в языке предложения "класс (или, если угодно, модуль) реализует интерфейс"; т.е. представление интерфейсов как отдельных сущностей, а не производных реализации класса (модуля).) В случае с модулями (в том же Oberon'е) использование интерфейсов в таком виде вряд ли возможно.

Наследование и полиморфизм я не стал приводить в аргументации, т.к. этими свойствами обладает концепция расширяемого типа данных, представленная в Oberon'е.

Пожалуйста, поправьте, если ошибаюсь...

Вот, собственно... Приношу извинения за столь длинное сообщение.

Ответ на »сообщение 3901« (Горбунов-Посадов)
___________________________

К сожалению, и здесь я не понимаю, что именно хотел сказать Вирт. Ведь добавление к программе кода, реализующего эллипс, должно, очевидно, сопровождаться добавлением к существующему меню нового пункта "Эллипс".

В диссертации Питера Мюллера http://oberon2005.ru/paper/eth14755.pdf есть раздел 3.6 Plugin Modules and Objects.
Там изложена концеция создания драйверов устройств путем создания абстрактного интерфейса устройства interface module, объекта реестра плагинов plugin registry object, и набора плагинов plugin modules, соответствующих конкретным устройствам. Плагины при этом могут подключаться динамически plugged in dynamically.