Ответ на »сообщение 3831« (Takun)
___________________________
Оно бы хорошо, но как быть с

VAR A:ARRAY M.Len OF INTEGER;

Запретить?

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

Сергей, тенденция такова, что в конечном счете Вам придется поставлять программы вместе со своей персональной версией Windows. :)

Что касается программирования в соответствии не с интерфейсом, а "фичами" (а скорее - "багами"), то при таком подходе ошибки будут всегда - и при динамической, и при статической линковке.

Я вижу единственное спасение - "контрактное программирование" охаянного здесь Мейера (не все же у него плохо!). Нарушение "контракта" наказывается сразу и публично.
Вот тогда ошибки при использовании чужих компонентов исчезнут. Ну, почти. :)
<...>
Причина ненадежности не в динамической загрузке как таковой, а в программировании в соответствии с "фичами", что, в свою очередь, вызвано ошибками в "стандартных" компонентах и несоразмерной сложностью их использования (сравнить хотя бы OLE/COM с взаимодействием модулей в Обероне!).
Я согласен, что вопрос непростой.
Надо думать.

Посмотрите на зоопарк, который творится в мире программирования J2ME: каждый из вендоров аппаратно-программной платформы по-своему понимал новую и несовершенную спецификацию MIDP1.0 и клепал собственную реализацию, делая приправу из собственных нативных фич (доступ к файловой системе у Siemens, собственный "расширенный" GUI у Nokia и т.д.). Теперь этот зоопарк перерождается в другую фазу - на рынок вышли новые вендоры со своими фичами, а "старички" уходят на более внятную MIDP2.0. :p
Что более удивительно так это то, что разработчики никоим образом не стремяться абстрагироваться от частностей реализации, а напрямую используют "грязный хак", специально затачивая разработки под КОНКРЕТНЫЕ мобилы. В итоге порождается куча кастомизационных вещей и дублирующего кода в виде ЦЕЛЕВОЙ КОМПИЛЯЦИИ под конкретные аппараты. (например, исходники мобильной аськи Jimm занимают 25МБ, тогда как рабочий модуль ~100КБ)
Фсё. Круг замкнулся.

Вот она - Java. От чего долго-долго уходили и к чему впоследствии вернулись - к сишному разброду и шатанию в исходниках.

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


Допустим Вы обнаружили в каком-то библиотечном модуле ошибку. Исправили и перезагрузили -- и все дела. И часть программ стала работать не правильно. Потому, что с их точки зрения это была "не ошибка, а особенность". Вот отсюда и возникает ад dll.
Сколько раз отлаженные программы не желали работать при переносе на другую машину, где была установлена другая версия (ИСПРАВЛЕННАЯ :o)) какой нибудь dll.


Сергей, тенденция такова, что в конечном счете Вам придется поставлять программы вместе со своей персональной версией Windows. :)

Что касается программирования в соответствии не с интерфейсом, а "фичами" (а скорее - "багами"), то при таком подходе ошибки будут всегда - и при динамической, и при статической линковке.

Я вижу единственное спасение - "контрактное программирование" охаянного здесь Мейера (не все же у него плохо!). Нарушение "контракта" наказывается сразу и публично.
Вот тогда ошибки при использовании чужих компонентов исчезнут. Ну, почти. :)


Пожалуйста, дайте мне компоновщик, только тогда я буду уверен, что никто в мою программу не внесет "исправления".


Что касается именно компоновщика, то это все есть, далеко ходить не надо.
Например, XDS и не даст Вам другого варианта кроме статической линковки.
BlackBox позволяет упаковать Ваш релиз целиком в один exe-файл. Чем не аналог статического линковщика?


Конечно, с точки зрения ресурсов, помодульная загрузка экономичнее. Но что будет с надежностью?  


Причина ненадежности не в динамической загрузке как таковой, а в программировании в соответствии с "фичами", что, в свою очередь, вызвано ошибками в "стандартных" компонентах и несоразмерной сложностью их использования (сравнить хотя бы OLE/COM с взаимодействием модулей в Обероне!).
Я согласен, что вопрос непростой.
Надо думать.

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

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

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

Ответ на »сообщение 3823« (Руслан Богатырев)
...(timestamp/checksum, причем внутри каждого модуля эту пару для каждого импортируемого им модуля)...

Не модуль снабжается фингерпринтом, а каждая экспортируемая модулем сущность! Каждая экспортируемая константа, каждая экспортируемая переменая, процедура и тип - у каждой экспортируемой сущности свой фингерпринт.

Из серии "в огороде бузина, а Киеве -- дядька".

Я про timestamp/checksum всего модуля -- мне в ответ про fingerprint сущностей.

Простите, о чем мы толкуем? Я про свое предложение (что делалось во многих реализациях Modula-2), где фиксируется модуль в целом (фиксируя дату компиляции!, это понятно?), а вы про другой подход. Почитайте повнимательнее, разберитесь.

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


Не модуль снабжается фингерпринтом, а каждая экспортируемая модулем сущность! Каждая экспортируемая константа, каждая экспортируемая переменая, процедура и тип - у каждой экспортируемой сущности свой фингерпринт.

Не много ли оверхеда, например, на байтовую константу?

Ответ на »сообщение 3832« (Сергей Перовский)
...Мы пришли к тому, от чего пытаемся уходить...

Мы бы пришли к этому если бы Руслан Богатырев был прав. Но он в данном случае заблуждается.

Ответ на »сообщение 3823« (Руслан Богатырев)
...(timestamp/checksum, причем внутри каждого модуля эту пару для каждого импортируемого им модуля)...

Не модуль снабжается фингерпринтом, а каждая экспортируемая модулем сущность! Каждая экспортируемая константа, каждая экспортируемая переменая, процедура и тип - у каждой экспортируемой сущности свой фингерпринт.

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


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

В современной Java (Java2) возможно создание четырёх вложенных (nested) классов. Их виды:
* класс-член (nonstatic member class)
* статический класс (static member class)
* анонимный класс (anonymous class)
* локальный класс (local class)
Каждый из них наделён определёнными правами доступа к другим членам (даже к закрытым) класса, в котором они определяются. В общем, это механизм, призванный как можно гибко решить проблему передачи ссылки this в случае объекта-владельца и Class.this в случае класса-владельца информации о типе (метакласс).
Ну да не суть важно.

Под модульностью в ООП я ставлю знак равенства между модулем и объектом. Но в случае, если у класса есть  статические члены, то и между понятием модуля и этим классом_со_статическими_членами.

Класс_без_статических_членов не может представлять из себя модуль, в нём нет "капсулы", в которой инкапсулированы реальные данные. То же относится и к интерфейсам Java.

Кстати, про интерфейсы Java (немного отвлечёмся). Очень занятно то, что объявленные в них константы напрямую линкуются в реализующие эти интерфейсы классы!!! Это начит, что при изменении интерфейса с константами нужно перекомпилировать все классы, которые его имплементируют, что никак нельзя назвать модульностью. Вообще-то хорошим тоном считается не определять в интерфейсах никаких констант для передачи их в реализующие классы; интерфейс служит для определения типов и ничего другого, хотя в исходниках многих промышленных продуктов на Java это правило нарушается, даже в самом JDK (см. java.io.ObjectStreamConstants).

Ну ладно. Это всё детали. Главное - в Java возможны "внутренние модули".

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

В Java возможны "внутренние модули" и они нужны в первую очередь чтобы не загромождать внешние связи передачами ссылок на объект-экземпляр класса и на сам класс. Так называемые классы-хелперы, помогающие клиентам работать с основным классом: Итераторы, Операции по обходу структуры объекта, Компараторы, Сериализаторы, Слушатели событий в технике JavaBeans, да и много зачем ещё могли бы понадобиться "внутренние модули". "Внутренние модули" необязательно должны быть видны клиентам, это - просто очередной уровень абстракции, помогающий структурировать информацию для человека-разработчика.

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

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

Интересно, оданко получается.

1. Соответствие модулей фиксируется только интерфейсом. Динамическое связывание. Динамическая подгрузка/выгрузка. Вам не подходит.

2. Статическая сборка всех модулей. Вам не подходит.

3. Компромиссный вариант: часть собирается статически (точнее, статически устанавливаются зависимости от версий), а другая - динамически, причем есть возможность управлять: статические переводить в динамические и наоборот. Вам не подходит.

Предложите четвертый вариант.

Ответ на »сообщение 3823« (Руслан Богатырев)
___________________________
Мне хотелось бы покрасить
Бакенбарды в цвет зеленый,
В руки веер взять побольше,
Чтобы их никто не видел (с)

>>А далее иметь специальный конфигуратор, который позволял бы снимать/ослаблять контроль на предмет подмены модулей на лету.
Мы пришли к тому, от чего пытаемся уходить: на компьютере придется хранить (и одновременно загружать) несколько версий одного модуля, и со своей программой передавать все необходимые модули (а вдруг у клиента не та версия).
Для надежности все разработчики будут указывать точные версии используемых сторонних модулей и экономия будет только в случае если у загруженных программ случайно совпала версия используемого модуля.
И за это мы должны заплатить созданием интелектуального компоновщика-загрузчика?
Мне кажется, что это очень напоминает тот путь, который уже прошел майкрософт, создав по сути компонентную, расширяемую операционную систему.
Они нахлебались проблем и теперь ищут альтернативу. NET, по сути, попытка сбежать с этого корабля.