Ответ на »сообщение 3920« (Горбунов-Посадов)
___________________________
Не знаю, это ли имел в виду уважаемый коллега, но все когда-либо написанные мной программные продукты по объему не превосходили 10-15 тыс. строк исходного кода. Да и по качеству кода их можно отнести к посредственным.
Хм…
Однако расширяемые конструкции, о которых я тут упоминаю, имели совсем другую отправную точку. Мне посчастливилось писать инструментальные средства для проектов объемом порядка нескольких сотен тысяч строк исходного кода. Не просто кода, а продукта, десятилетиями отшлифованного до завораживающего блеска и в то же время непрерывно и весьма энергично изменяющегося. Корифеям, занятым увлекательными задачами типа математического моделирования управляемого термоядерного синтеза, было не до рассуждений об используемой в их продуктах технологии программирования. И я попытался это сделать за них.
Большая система не определяется объемом кода, большая система – это архитектура нескольких логически самостоятельных уровней. Мне довелось в свое время познакомиться с Вашими идеями по Вашим книгам, но они не имеют прямого отношения к большим системам. Вы говорили(те) о каркасах, но в большой системе нет устойчивого каркаса, здесь каркас, его устройство и текущее состояние определяется самостоятельным уровнем логики, независимым от логик других уровней. Если заменить программную реализацию Вашего каркаса, на программную реализацию логики, то мы с Вами сможем лучше понимать друг друга. Для примера посмотрите на систему http://cube.lex-it.ru . Уровень, на котором происходит связь различных подсистем (планирование) «отвязан» от самих подсистем, и ему совершенно безразлично какие подсистемы он связывает между собой. При этом каждая подсистема сама является системой, то есть, состоит из элементов. И элементы подсистемы ничего не знают друг о друге, они связаны вместе логикой подсистемы и эти связи могут быть перестроены. Если есть желание, то можно разобрать более простой пример, но, наверное, лучше в другой «ветке».
Об инструментальном подходе при построении больших систем можно посмотреть публикации на http://www.alexus.ru/russian/articles.htm
В то же время ни один из обслуживаемых нашими инструментальными средствами программных проектов не выходил, насколько я знаю, за пределы одного-двух миллионов строк исходного кода. Так что если уважаемый коллега имеет в виду объемы в десятки миллионов строк и более, то легко соглашусь с тем, что с таких высот ему открылись новые, существенно более интересные горизонты.
Оценки, вынесенные на основе объема кода, являются весьма спорными. Известно, что хороший программист напишет программу более кратко и эффективно, чем плохой программист. Это, согласитесь, не означает, что большие системы пишутся плохими программистами.

Ответ на »сообщение 3959« (Как слышно? Прием!)
___________________________

Давай, дедушка, я тебе помогу! У Вас с терминами как пробка на МКАД.

Согласно ГОСТ 19781-90.

Подскажите, как согласно ГОСТ выделяется
1. модуль в языке программирования,
2. модуль как результат трансляции,
3. модуль как единица загрузки
4. модуль как часть архитектуры системы?

Это все обозначает один термин?

Модуль предназначен для хранения, трансляции, объединения с другими программными модулями.

Как вы понимаете, это нельзя считать полезным определением модуля, ибо оно, как минимум, рекурсивное. Хочу заметить, что просто дать определение -- бессмысленная вещь. Требуется такое определение, которое бы позволило достаточно четко выявлять соответствие данной категории.

Чтобы любое постороннего человека можно было спросить: вот это модуль? И он, пользуясь, определением, ответил -- да или нет, причем смог бы это обосновать.

Возьмем, к примеру, header-файлы языка Си. Подпадают они под приведенное вами определение из ГОСТ? Подпадают. Являются модулями? С моей точки зрения, нет.

Фактически такое определение ГОСТ можно подвести под любой файл, которые используется на этапах трансляции и линковки (объединения)!

И что такое определение дает нам в свете анализа возможностей модулей и классов? Ровным счетом НИЧЕГО.

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

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

Не все так просто и однозначно. Кавалерийскими наскоками и советами убогим и пожилым здесь не обойтись. Увы.

Давай, дедушка, я тебе помогу! У Вас с терминами как пробка на МКАД.

Согласно ГОСТ 19781-90.

Модуль предназначен для хранения, трансляции, объединения
с другими программными модулями.

Объектный модуль - программа с неразрешенными внешними ссылками.

Объект - модуль, объединяющий в себе данные и операции над ними,
обладающий свойствами наследования и полиморфизма.

Аминь!

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

Маленькое отступление от темы.
Меня всегда смущало то, как по-русски звучит словосочетание "расширяемая система" (калька с extensible system).
Ну, не нравится оно мне, кажется что кто-то там чего-то "ширяет".
Почему бы нам не называть такие системы открытыми?
В нашем контексте "открытая система" = "система, открытая для расширений" = "расширяемая система".
А звучит гораздо лучше. :)

Нет, пусть уж лучше "расширяемая" !

система может быть открыта не только для расширений

Маленькое отступление от темы.
Меня всегда смущало то, как по-русски звучит словосочетание "расширяемая система" (калька с extensible system).
Ну, не нравится оно мне, кажется что кто-то там чего-то "ширяет".
Почему бы нам не называть такие системы открытыми?
В нашем контексте "открытая система" = "система, открытая для расширений" = "расширяемая система".
А звучит гораздо лучше. :)

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

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


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


Мессенбек (автор Оберона-2) написал интресную статью "Extensibilty in the Oberon System".
Подводя итог одному из примеров, он пишет:

"The extensibility in this example comes from the following characteristics of the Oberon System:
(1) The object-oriented nature of the language allows us to extend the type Element and to treat the
extensions in the same way as their base type.
(2) Dynamic loading makes it possible to add the new hypertext module to the editor at run time.
(3) Commands allow us to invoke the new functionality directly without having to modify the
menus in the existing editor.
(4) Since all modules share the same address space, the hypertext module can insert elements in the
piece list which belongs to a module of the base system."

Опять же, как и в книге Рейзера и Вирта, новая функциональность добавляется вызовом команды.
Можно предположить, что понятие команды и возможность вызывать команды непосредственно из текста, являются важной предпосылкой расширяемости Оберон-системы.
Ясно, что кроме того можно определить команду регистрации, которую достаточно вызвать один раз, и она добавит соостветствующие пункты во все соответствующие меню, которые затем будут сохранены как persistent objects.

В BlackBox есть и другой способ, родственный Вашему двумерному способу представления расширяемых систем.
У каждой подсистемы есть свой каталог, соответствующий вертикальному слою системы (компоненту), а также подкаталоги Mod и Rsrc, которые можно поставить в соответствие двум горизонтальным слоям -- в данном случае, кода и ресурсов (меню и т.д.).
Компонент может определить оба слоя. Тогда содержащаяся в коде функциональность может быть сразу задействована с помощью меню, т.к. пункты меню будут автоматически добавлены в BlackBox при загрузке.
Но это уже деталь.
Главное, что новая функциональность может быть активирована простым вызовом команды.
Пока что необходимости в (пере)трансляции исходников не видно (имхо).
Может быть, что-то все время проходит мимо моего сознания.


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


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

Вообще данная статья Мессенбека интересна.
Например, там проводится параллель между вызовом команды (у модуля) и вызовом метода (у класса).
Повторяется известная мысль, что в Обероне

"There is no difference between a user-written module and a system module. Programming in Oberon therefore always means extending the operating system."

P.S. Хочу частично поддержать Сергея Губанова.
ИМХО, мы пытаемся не просто дать понятие модуля, а разобраться в понятии расширяемой системы.
Как мне кажется, именно об этом хочет сказать Сергей.

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

а вот как при этом обойтись без перетрансляции -- не знаю.

Возникает впечатление, что трудность, о котороый Вы тут говорите, -- именно та, которая решается стандартной обероновской схемой:

PROCEDURE (v: View) HandleMsg ( VAR msg: Message ),

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

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

... в КП это объявляется как устаревшая возможность. И если следовать логике этого языка и восприятия процедурных переменных как goto, то это может привести к отказу от поддержки этой возможности в BlackBox-реализации КП в обозримом будущем.

Надоели уже эти страшилки.
Можно подумать, что Куно Пфистер полный идиот, а не один из лучших sw-архитекторов в мире.

Максимум, что можно ожидать -- перенесут процедурные переменные в разряд SYSTEM-средств.

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

Ответ на »сообщение 3924« (Сергей Губанов)
___________________________

Однако мне непонятна Ваша трактовка модуля и модуля систем. ...
В случае с Delphi можно сделать так, чтобы откомпилированные модули (unit) хранились в отдельных файлах и подгружались автоматически при обращении к ним -- всё упирается в среду исполнения.

"Модульных систем".
Но Вы сами разъясняете ("всё упирается в среду...") смысл, который пытается донести С.Г.

Ответ на »сообщение 3949« (Сергей Перовский)
___________________________

to:  Сергей Губанов ... Никто не может понять, в каком смысле Вы эти слова используете.

Ну зачем же так обобщать :-)

Сергей Губанов (насколько понимаю) использует слово модуль в том же смысле, в каком оно использовано в Оберонах.