Здравствуйте, Kluev, Вы писали:
K>Такого быть не должно. На этапе компиляции должна отслеживатся обратная совместимость и уже существующие сигнатуры не должны изменятся или удалятся. Только добавление новых.
Это как это? Мой модуль — как хочу так его и изменяю. К тому же это невозможно технически. Ведь компилятору (и автору модуля тоже) не известны модули-клиенты (да и их количество ни чем не ограничено), а известны только импортируемые модули.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>А я, наконец-то, понял, Вы говорите, что слова "контроль версий типов во время выполнения программы" и слова "контроль необходимости перекомпиляции" обозначают разные вещи. Естественно это так.
СГ>Я то всё время, говоря об инвалидации модулей-клиентов одновременно добавлял еще одну фразу: "а значит их нужно перекомпилировать". Естественно, что можно было эту вторую фразу не добавлять, а просто говорить об инвалидации модулей-клиентов. Теперь Ваше сообщение стало мне понятно.
Теперь осталось еще понять, что даже если тип не изменился, но изменились типы, от которых он зависит — то тип все равно должен считаться инвалидированным.
Плюс к этому надо учитывать неявные зависимости от других типов через совместно используемые данные.
Здравствуйте, Дарней, Вы писали:
Д>Теперь осталось еще понять, что даже если тип не изменился, но изменились типы, от которых он зависит — то тип все равно должен считаться инвалидированным.
Это всё, естественно, учитывается.
Д>Плюс к этому надо учитывать неявные зависимости от других типов через совместно используемые данные.
А вот это уже будет лишний двойной учет. Данные — это экспортируемая переменная. Если она достаточно сильно изменена, то импортирующий ее модуль уже инвалидируется. А раз он и так уже инвалидирован, то больше не надо искать других причин для его инвалидации, достаточно одной причины.
Здравствуйте, Сергей Губанов, Вы писали:
Д>>Теперь осталось еще понять, что даже если тип не изменился, но изменились типы, от которых он зависит — то тип все равно должен считаться инвалидированным.
СГ>Это всё, естественно, учитывается.
Описаний того, как это происходит, я не видел.
СГ>Данные — это экспортируемая переменная. Если она достаточно сильно изменена, то импортирующий ее модуль уже инвалидируется.
НЕ экспортируемая переменная. Внутренняя переменная, которая совместно используется несколькими типами в пределах импортированной сборки.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Kluev, Вы писали:
K>>Такого быть не должно. На этапе компиляции должна отслеживатся обратная совместимость и уже существующие сигнатуры не должны изменятся или удалятся. Только добавление новых.
СГ>Это как это? Мой модуль — как хочу так его и изменяю. К тому же это невозможно технически. Ведь компилятору (и автору модуля тоже) не известны модули-клиенты (да и их количество ни чем не ограничено), а известны только импортируемые модули.
Тогда никто кроме тебя им пользоватся и не будет. А хочешь делать компонент для использования в других программах обеспечь обратную совместимость. Или делай несовместимые версии с разными именами.
СГ>К тому же это невозможно технически
Что? невозможно обеспечить обратную совместимость? Это легко делается даже в с. старые сигнатуры не меняй, новые добавляй. Все будет работать
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Сергей Губанов, Вы писали:
Д>>>Теперь осталось еще понять, что даже если тип не изменился, но изменились типы, от которых он зависит — то тип все равно должен считаться инвалидированным.
СГ>>Это всё, естественно, учитывается.
Д>Описаний того, как это происходит, я не видел.
Так увидьте! Вы ту диссертацию (ссылка №8) уже скачали? Исходные коды Блэкбокса уже посмотрели?
СГ>>Данные — это экспортируемая переменная. Если она достаточно сильно изменена, то импортирующий ее модуль уже инвалидируется.
Д>НЕ экспортируемая переменная. Внутренняя переменная, которая совместно используется несколькими типами в пределах импортированной сборки.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Так увидьте! Вы ту диссертацию (ссылка №8) уже скачали? Исходные коды Блэкбокса уже посмотрели?
у меня просто нет на это время. Точнее, овчинка не стоит выделки — и так видно, что оберон слишком плохо продуман. Хотя какие-то хорошие идеи там возможно и есть.
СГ>Я не понял о чем Вы.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Для опровержения Вашего заявления, здесь список защищенных по оберонам и оберон-системам диссертаций/книг/публикаций. Все они очень хорошо продуманы.
Это мы уже слышали, начинать бесплодный спор сначала у меня желания нет.
Поэтому я просто скажу — как практик, я не считаю эту систему пригодной для широкого применения. Точка.
