о странном способе импорта модулей принятом в дотнете (конкретно там речь шла только об импорте констант, но на самом деле, тоже самое можно сказать об импорте любых объектов). Я недоумевал почему в дотнете с этим делом все так плохо, в то время как в оберонах с этим же делом все обстоит хорошо. Вчера, прочитав следующий материал:
Оказывается в оберонах каждый экспортируемый модулем объект помечается своим собственным уникальным идентификатором (можете называть его как пожелаете — номер версии, подпись и т.п.). То есть не весь модуль целиком имеет один единственный уникальный идентификатор версии модуля, а каждый экспортируемый этим модулем объект имеет свой автоматически генерируемый персональный уникальный идентификатор версии.
Например, пусть модуль M экспортирует две константы M.c1 = 1 и M.c2 = 2. Каждая из этих констант будет снабжена своим собственным уникальным идентификатором версии. Допустим, теперь есть два модуля X и Y импортирующих модуль M (т. е. являющихся его клиентами), один из которых — X пусть использует только константу M.c1 = 1, а другой — Y пусть использует только константу M.c2 = 2. Теперь мы внесли изменение в модуль M, а именно изменили значение первой константы на другое, пусть теперь M.c1 = 0. Что будет? Надо ли перекомпилировать все модули-клиенты модуля M? Нет, все — не надо. Надо перекомпилировать только те модули-клиенты, которые использовали M.c1 = 1. При попытке запустить на исполнение модуль X загрузчик/линковщик сообщит об ошибке импорта константы M.c1 в модуле X, он просто сравнит версию этой константы с версией этой же константы хранимой в скомпилированном модуле X. То есть модуль X надо перекомпилировать. Но модуль Y будет исполняться как ни вчем ни бывало, ведь он не использует константу M.c1, его перекомпилировать не надо. Сказанное относится не только к константам, но и ко всем остальным экспортируемым модулем объектам.
На самом деле на этом приключения с экспортом-импортом не заканчивается. Есть еще один вопрос —
Цепочка импорта
Что если один модуль импортирует другой, а тот, в свою очередь, импортирует третий модуль, причем так, что первый модуль неявно его использует. В дотнете, оказывается надо добавить в список ссылок сборки и тот модуль тоже! Иначе получим вот такую ругань от компилятора:
***.dll Referenced class '***' has base class or interface '***' defined in an assembly that is not referenced. You must add a reference to assembly '***'.
То есть в дотнете в список импортируемых модулей должны быть включены все нужные модули, затем все модули нужные нужным модулям и рекурсивно так далее. В оберонах этого делать не нужно. В оберонах, если один модуль импортирует какие-то объекты из другого модуля, то информация о них (вместе с их номерами версий) просто копируется в его символьный файл. Импортировал он константу, вот только эта константа и будет добавлена. Ни откуда не следует, что размер символьных файлов по ходу цепочки будет становится все больше и больше. Ничего подобного, он может, наоборот, становится все меньше и меньше. Все зависит от того что будет экспортировано дальше, а что останется инкапсулированным. На самом деле символьные файлы на столько малы, что как было замечено Мёсенбёком, зачастую читаются с диска всего одной операцией чтения. Допустим теперь есть несколько модулей импортировавших один и тот же объект (из одного и того же модуля естественно) т.е. у каждого из них есть копия информации о том объекте. Ничего страшного — загрузчик/линковщик сверит версии копий информации об этом объекте и в зависимости от результата либо загрузит+слинкует модули либо выдаст сообщение об ошибке импорта.
P. S. Ханспетер Мёссенбёк – соавтор Н.Вирта по языку Оберон-2
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Оказывается в оберонах каждый экспортируемый модулем объект помечается своим собственным уникальным идентификатором (можете называть его как пожелаете — номер версии, подпись и т.п.). То есть не весь модуль целиком имеет один единственный уникальный идентификатор версии модуля, а каждый экспортируемый этим модулем объект имеет свой автоматически генерируемый персональный уникальный идентификатор версии.
Очень интересно, по какому алгоритму уникальные идентификаторы объектов меняются. Я так понял, идентификатор изменяется при перекомпиляции в случае, если объект изменился относительно последней скомпилированной версии модуля?
Здравствуйте, Oyster, Вы писали:
O>Очень интересно, по какому алгоритму уникальные идентификаторы объектов меняются. Я так понял, идентификатор изменяется при перекомпиляции в случае, если объект изменился относительно последней скомпилированной версии модуля?
Идентификатор (fingerprint) объекта вычисляется при компиляции как "контольная сумма" из его определения.
Здравствуйте, Oyster, Вы писали:
O>Очень интересно, по какому алгоритму уникальные идентификаторы объектов меняются. Я так понял, идентификатор изменяется при перекомпиляции в случае, если объект изменился относительно последней скомпилированной версии модуля?
Этот вопрос меня тоже интересует. Вообще, ответ изложен у, как я понял, автора этого метода в его диссертации:
Regis Creiler "Separate Compilation and Module Extension". ETH dissertation 1994
осталось только ее раздобыть.
Второй способ найти ответ заключается в том чтобы покопаться в исходниках, например, Блэкбокса.
Здравствуйте, stalcer, Вы писали:
Т>>Идентификатор (fingerprint) объекта вычисляется при компиляции как "контольная сумма" из его определения. S>Тогда теоретически два разных определения объекта могут иметь одну и ту же контрольную сумму, со всеми вытекающими последствиями.
Контрольная сумма в каком-либо секторе твоего винта может соответствовать разным данным. Тогда теоретически твои данные могут попортиться так, что контрольная сумма останется той же, со всеми вытекающими последствиями.
Здравствуйте, Кодёнок, Вы писали:
Кё>Контрольная сумма в каком-либо секторе твоего винта может соответствовать разным данным. Тогда теоретически твои данные могут попортиться так, что контрольная сумма останется той же, со всеми вытекающими последствиями.
Сравнил, блин.
Если я на винте вообще уберу эту контрольную сумму, то все будет по прежнему работать, так как это только дополнительная мера предосторожности. А в случае версий объектов, это, извините, часть основного алгоритма.
Здравствуйте, stalcer, Вы писали:
S>Если я на винте вообще уберу эту контрольную сумму, то все будет по прежнему работать, так как это только дополнительная мера предосторожности. А в случае версий объектов, это, извините, часть основного алгоритма.
Надо ту диссертацию раздобыть и прочитать, а то так это гадание на кофейной гуще.
Здравствуйте, stalcer, Вы писали:
S>Если я на винте вообще уберу эту контрольную сумму, то все будет по прежнему работать, так как это только дополнительная мера предосторожности. А в случае версий объектов, это, извините, часть основного алгоритма.
MD5 — это тоже часть основного алгоритма цифровой подписи. И хотя хэш-функция может быть одинаковой для разных документов, это никому не мешает.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Оказывается в оберонах каждый экспортируемый модулем объект помечается своим собственным уникальным идентификатором (можете называть его как пожелаете — номер версии, подпись и т.п.). То есть не весь модуль целиком имеет один единственный уникальный идентификатор версии модуля, а каждый экспортируемый этим модулем объект имеет свой автоматически генерируемый персональный уникальный идентификатор версии.
Если код самого класса не изменился, то это не значит, что не изменилось поведение этого класса. Потому что он зависит от других классов, которые определены в этом и/или других модулях, которые могли измениться независимо от него.
Модульная организация в .NET может дать гарантию, что программа будет использовать точно ту версию класса (и классов, от которых он зависит), с которой она была скомпилирована. Модульная организация оберонов такой гарантии не дает.
И что мы имеем в сухом остатке? Очередная война с ветряными мельницами.
Здравствуйте, Дарней, Вы писали:
Д>Если код самого класса не изменился, то это не значит, что не изменилось поведение этого класса. Потому что он зависит от других классов, которые определены в этом и/или других модулях, которые могли измениться независимо от него.
Смотрите пункт про цепочку импорта.
Д>Модульная организация в .NET может дать гарантию, что программа будет использовать точно ту версию класса (и классов, от которых он зависит), с которой она была скомпилирована. Модульная организация оберонов такой гарантии не дает.
Всё наоборот. В оберонах это гарантируется автоматически, а .NET ни каких гарантий не дает — тут программист сам должен обо всем не забыть позаботится. Он должен ручками менять номер версии всего модуля при этом обрекая все остальные модули-клиенты на перекомпиляцию даже если фактически они в ней и не нуждались. В доказательство этого я приводил пример не то что для классов, а даже для более простой вещи — для экспорта двух констант, одна из которох в последствии меняется. Для классов можете проверить это самостоятельно.
Здравствуйте, Дарней, Вы писали:
Д>Если код самого класса не изменился, то это не значит, что не изменилось поведение этого класса. Потому что он зависит от других классов, которые определены в этом и/или других модулях, которые могли измениться независимо от него.
В некоторых случаях как раз такое поведение и нужно. Для того, чтобы перекомпилировать как можно меньше, а значит — быстрее.
А вроде в предадущем топике речь шла о том, что когда константа меняется, то ничего перекомпилиловать не нужно и все правильно работает.
А тут получается, что все-таки нужно?
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Смотрите пункт про цепочку импорта.
Я не вижу там ничего про рекурсивную проверку версий всех классов, от которых зависит интересующий нас класс. Но даже такой проверки недостаточно, поскольку зависимости могут быть косвенными — через разделяемые данные, например.
СГ>Он должен ручками менять номер версии всего модуля при этом обрекая все остальные модули-клиенты на перекомпиляцию даже если фактически они в ней и не нуждались. В доказательство этого я приводил пример не то что для классов, а даже для более простой вещи — для экспорта двух констант, одна из которох в последствии меняется. Для классов можете проверить это самостоятельно.
Отделим мух от котлет. Во первых, номер версии сборки меняется автоматически.
Во вторых — эти перекомпиляции не лишние. На текущем уровне развития систем разработки им не хватает интеллектуальности, чтобы определить, что "эта версия кода ведет себя точно так же, как предыдущая". Поэтому лучше перестраховаться, чем потом наступить на грабли.
И в третьих — если тебе так уж приспичило использовать отдельную сборку с константой, просто сделай ее static readonly, а не const. Хотя про это уже раз десять говорили, кажется.
Здравствуйте, stalcer, Вы писали:
S>В некоторых случаях как раз такое поведение и нужно. Для того, чтобы перекомпилировать как можно меньше, а значит — быстрее.
Это некритично. Если народ мирится со скоростью работы приплюснутого препроцессора, то уж лишние перекомпиляции в .NET точно переживет.
Здравствуйте, stalcer, Вы писали:
S>А вроде в предадущем топике речь шла о том, что когда константа меняется, то ничего перекомпилиловать не нужно и все правильно работает. S>А тут получается, что все-таки нужно?
Да нет, это была фантазия. Дескать, а вот бы было бы так чтобы не надо было перекомпилировать модули самому, вот кайфно бы тогда стало. То есть теоретически, если компилировать сами исходники (пусть даже на промежуточном компактном языке) все перед каждым запуском (отказаться от заранее скомпилированных в машинные коды бинарных модулей), то вроде такого можно было бы добиться.
Здравствуйте, Дарней, Вы писали:
Д>Я не вижу там ничего про рекурсивную проверку версий всех классов, от которых зависит интересующий нас класс. Но даже такой проверки недостаточно, поскольку зависимости могут быть косвенными — через разделяемые данные, например.
Рекурсивная проверка и не нужна. Читайте внимательнее пункт "6 Separate Compilation".
Д>Во вторых — эти перекомпиляции не лишние. На текущем уровне развития систем разработки им не хватает интеллектуальности, чтобы определить, что "эта версия кода ведет себя точно так же, как предыдущая". Поэтому лучше перестраховаться, чем потом наступить на грабли.
У оберонов на это элементарное дело ума хватает, а у дотнета нет.
Д>И в третьих — если тебе так уж приспичило использовать отдельную сборку с константой, просто сделай ее static readonly, а не const. Хотя про это уже раз десять говорили, кажется.
Константы — это только для примера, вместо них можно было бы рассмотреть что угодно другое.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Дарней, Вы писали: Д>>И в третьих — если тебе так уж приспичило использовать отдельную сборку с константой, просто сделай ее static readonly, а не const. Хотя про это уже раз десять говорили, кажется.
СГ>Константы — это только для примера, вместо них можно было бы рассмотреть что угодно другое.
Что конкретно?
Не надо кидаться фразами про "что угодно" если фактами не располагаешь, я думаю...
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Рекурсивная проверка и не нужна. Читайте внимательнее пункт "6 Separate Compilation".
Правда не нужна? Наверно, в программах на обероне функциональность каждого класса не зависит от других классов никаким образом.
СГ>У оберонов на это элементарное дело ума хватает, а у дотнета нет.
Я пока что заметил, что им хватает ума только на раскладывание тщательно замаскированных граблей.
Здравствуйте, Дарней, Вы писали:
Д>Это некритично. Если народ мирится со скоростью работы приплюснутого препроцессора, то уж лишние перекомпиляции в .NET точно переживет.
Народ не мирится, а извращается. Так вот, например:
class MySuperClassImpl;
class MySuperClass
{
public:
void myVeryComplexFunction(...);
private:
MySuperClassImpl *m_impl;
};
Здравствуйте, stalcer, Вы писали:
S>Народ не мирится, а извращается. Так вот, например:
Даже с костылями вроде предкомпилированных заголовков и таких вот фокусов средний проект на С++ компилируется минимум на порядок дольше, чем аналогичной сложности проект на C#
Припоминается мне один проект, полная перекомпиляция которого занимала почти сутки И ничего, живут ведь люди. Так что если перекомпиляция занимает 30 секунд, а не 10 — никто от этого точно не помрет
Здравствуйте, Дарней, Вы писали:
Д>Модульная организация в .NET может дать гарантию, что программа будет использовать точно ту версию класса (и классов, от которых он зависит), с которой она была скомпилирована. Модульная организация оберонов такой гарантии не дает.
Скорее так: Модульная организация оберона гарантирует, что используемый модуль имеет тот интерфейс, который использовался при компиляции, а модульная организация .NET позволяет гарантировать, что используемый модуль имеет ту же реализацию.
Здравствуйте, stalcer, Вы писали:
Д>>Это некритично. Если народ мирится со скоростью работы приплюснутого препроцессора, то уж лишние перекомпиляции в .NET точно переживет.
S>Народ не мирится, а извращается. Так вот, например:
S>
Идиома PImpl применяется не столько для уменьшения времени компиляции, сколько для обеспечения безопасности в случае исключений. Для сложных классов PImpl может быть единственным образом реализовать строгую гарантию безопасности для оператора копирования.
А сократить время компиляции можно, например, и так:
class MySuperClass
{
public :
virtual ~MySuperClass();
virtual void myVeryComplexFunction(...) = 0;
};
std::auto_ptr< MySuperClass > createMySuperClassImpl();
// Где-то в реализации.class MySuperClassImpl : public MySuperClass
{
...
};
std::auto_ptr< MySuperClass > createMySuperClassImpl()
{
return std::auto_ptr< MySuperClass >( new MySuperClassImpl );
}
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Что если один модуль импортирует другой, а тот, в свою очередь, импортирует третий модуль, причем так, что первый модуль неявно его использует. В дотнете, оказывается надо добавить в список ссылок сборки и тот модуль тоже! Иначе получим вот такую ругань от компилятора:
СГ>***.dll Referenced class '***' has base class or interface '***' defined in an assembly that is not referenced. You must add a reference to assembly '***'.
СГ>То есть в дотнете в список импортируемых модулей должны быть включены все нужные модули, затем все модули нужные нужным модулям и рекурсивно так далее.
Сборка A. Компилируется.
Сборка B, использует A. Добавляю референс на A. Компилируется.
Сборка C, использует B (неявно использует A). Добавляю референс на B (не добавляю референс на A). Компилируется.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>[..] Я недоумевал почему в дотнете с этим делом все так плохо, в то время как в оберонах с этим же делом все обстоит хорошо. [..]
Ну, "хорошо" — это ещё как посмотреть.
СГ>Уникальный идентификатор версии объекта[...]
Как же, проходили мы этот уникальный идентификатор для объекта. Помнится, называется эта модульная, неимоверно удобная среда COM. Сам по себе уникальный идентификатор версии объекта или сборки — эта выбор гранулярности метаинформации. Выше гранулярность — больше возможностей у среды исполнения. Но удобство программиста определяется не возможностями среды исполнения, а их реализацией. СГ>Цепочка импорта
Не надо путать людей: СГ>Что если один модуль импортирует другой, а тот, в свою очередь, импортирует третий модуль, причем так, что первый модуль неявно его использует. В дотнете, оказывается надо добавить в список ссылок сборки и тот модуль тоже!
И в оберонах тот же принцип — используете объекты, значит, надо добавлять ссылки, а, если, использования нет, то добавлять необязательно. Просто, в .NET'е наследование (в том числе непрямое) означает использование. В качестве примера отсутсвия использований прицепите к пустой сборке любой набор assembly. Все замечательно скомпилируется, никаких ошибок про неправильные ссылки.
СГ>То есть в дотнете в список импортируемых модулей должны быть включены все нужные модули, затем все модули нужные нужным модулям и рекурсивно так далее.
Неверно, необходимость добавления ссылок на сборку определяется наличием использования. СГ>Ни откуда не следует, что размер символьных файлов по ходу цепочки будет становится все больше и больше. Ничего подобного, он может, наоборот, становится все меньше и меньше.
Действительно, может, как и в .NET'е. Вот, только, я пока не видел на .NET'е проекты с тысячей assembly, а использовать тысячу объектов из библиотек в обероновском модуле — в это ещё могу поверить. СГ>На самом деле символьные файлы на столько малы, что как было замечено Мёсенбёком, зачастую читаются с диска всего одной операцией чтения.
А для .NET, надо полагать, стандартные пара десятков ссылок на assembly будут читаться дольше? Не верю. Равно как и в то, что время чтения ссылок вообще существенно для чего-либо. Думаю, что resolve ссылок (и в .NET и в оберонах) обычно требует больше дисковых операций.
Резюме: Уникальный идентификатор версии объекта хорошо, но недостаточно, чтобы в оберонах было лучше, чем в .NET'е. Цепочки — не согласен.
Здравствуйте, Дарней, Вы писали:
Д>MD5 — это тоже часть основного алгоритма цифровой подписи. И хотя хэш-функция может быть одинаковой для разных документов, это никому не мешает.
Если найдена хоть одна коллизия алгоритма хеширования, то ещё как мешает. MD5 уже лет семь как объявлена устаревшей.
А вот гос. стандарт США SHA-1, в которой ещё ни одной коллизии не найдено, но доказано что за 2^69 операций коллизию найти можно (сложнее чем коллизию MD5 = 2^64) и вот уже объявлен конкурс на создание нового стандарта по типу AES ... Опасно.
Шнаер в своём блоге описывал недавно прецедент в Австралийском суде по поводу MD5 — http://www.schneier.com/blog/archives/2005/08/the_md5_defense.html
Здравствуйте, Sergey J. A., Вы писали:
СГ>>***.dll Referenced class '***' has base class or interface '***' defined in an assembly that is not referenced. You must add a reference to assembly '***'.
СГ>>То есть в дотнете в список импортируемых модулей должны быть включены все нужные модули, затем все модули нужные нужным модулям и рекурсивно так далее.
SJA>Сборка A. Компилируется. SJA>Сборка B, использует A. Добавляю референс на A. Компилируется. SJA>Сборка C, использует B (неявно использует A). Добавляю референс на B (не добавляю референс на A). Компилируется. SJA>Что я не так делаю ?
Перечитаем внимательно сообщение:
***.dll Referenced class '***' has base class or interface '***' defined in an assembly that is not referenced. You must add a reference to assembly '***'.
В модуле В должен быть класс потомок класса определенного в модуле А или же реализующий интерфейс определенный в модуле А.
Здравствуйте, andyJB, Вы писали:
JB>Не надо путать людей:
Я людей не путаю. Перечитайте, указанную мной статью, там все понятно написано.
JB>Резюме: Уникальный идентификатор версии объекта хорошо, но недостаточно, чтобы в оберонах было лучше, чем в .NET'е.
В оберонах finger-print-ы имет каждый экспортируемый модулем объект (каждая константа, каждый тип и т.п.), в дотнете finger-print имеет только сам модуль целиком. Ну и разьве это не лучше? Это определённо (даже ультимативно!) лучше.
JB>Цепочки — не согласен.
Здравствуйте, Сергей Губанов, Вы писали:
JB>>Резюме: Уникальный идентификатор версии объекта хорошо, но недостаточно, чтобы в оберонах было лучше, чем в .NET'е.
СГ>В оберонах finger-print-ы имет каждый экспортируемый модулем объект (каждая константа, каждый тип и т.п.), в дотнете finger-print имеет только сам модуль целиком. Ну и разьве это не лучше? Это определённо (даже ультимативно!) лучше.
У меня есть маленькое такое замечание — в .NET строгое имя сборки определяется такими параметрами, как: собственно текстовым именем сборки (например, System.Data), версией сборки, локалью, публичным ключом и хэшем сборки, подписанным приватным ключом изготовителя сборки. В общем-то, "идентификатор" (строгое имя) сборки получается вещью более уникальной, чем Обероновский finger-print (контрольная сумма? судя по тому, что я прочитал).
В голову приходит простая аналогия: я могу залепить все запчасти своей машины (колёса, руль, дворники и т.д.) жвачкой, в надежде что её не удастся угнать, а могу поставить хорошую противоугонную систему (строгое имя) и застраховать тачку (подпись). Какой из этих двух вариантов "ультимативно лучше"?
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Это определённо (даже ультимативно!) лучше.
Д>ЧЕМ лучше?
Лучше — это когда как можно меньше модулей становятся негодными (подлежат перекомпиляции) при внесении изменений в импортируемый модуль.
Я привел простой пример с модулем из которого экспортировались две константы. При изменении только одной из них перекомпиляции подлежат только те модули, которые ее использовали. Модули использовавшие другую (не изменившуюся) константу перекомпилировать не нужно. В дотнете при изменении константы надо будет сменить версию модуля на другую, это приведет к инвалидации всех модулей-клиентов, в результате надо будет перекомпилировать все модули включая те, которые даже не использовали изменившуюся константу.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Лучше — это когда как можно меньше модулей становятся негодными (подлежат перекомпиляции) при внесении изменений в импортируемый модуль.
Расплатой за что является на порядок возросшая работа при загрузке программы в память. Сравни — как часто обычный пользователь программы компилирует, и как часто — запускает?
При этом, обрати внимание — гарантируется совместимость только на уровне интерфейсов, но не на уровне реализации.
СГ>Я привел простой пример с модулем из которого экспортировались две константы. При изменении только одной из них перекомпиляции подлежат только те модули, которые ее использовали. Модули использовавшие другую (не изменившуюся) константу перекомпилировать не нужно. В дотнете при изменении константы надо будет сменить версию модуля на другую, это приведет к инвалидации всех модулей-клиентов, в результате надо будет перекомпилировать все модули включая те, которые даже не использовали изменившуюся константу.
А насколько часто возникает необходимость изменить в модуле одну-единственную константу? (я уж не говорю о том, что куда уместнее использовать для хранения параметров файлы конфигурации)
Здравствуйте, stalcer, Вы писали:
S>Ню ню. Это не составит и пяти процентов от того, что делает VM при загрузке программы/модуля.
S>И вообще. Формат файлов ассемблей в .Net вообще не заточен под быструю загрузку. Скорее они старались их сделать как можно более компактными.
При всем этом, увеличивать затраты без соответствующих выгод смысла нет. И где же они (выгоды, в смысле)? Возможность использовать сборки с константами вместо файлов конфигурации?
Здравствуйте, Дарней, Вы писали:
Д>При всем этом, увеличивать затраты без соответствующих выгод смысла нет. И где же они (выгоды, в смысле)? Возможность использовать сборки с константами вместо файлов конфигурации?
Ты что же, правда не понимаешь разницу между константами и параметрами, которые следует выносить в файлы конфигурации?
Здравствуйте, stalcer, Вы писали:
S>Ты что же, правда не понимаешь разницу между константами и параметрами, которые следует выносить в файлы конфигурации?
Обсуждаемый здесь вопрос может и не так критичен для обыкновенных программ, разрабатываемых на дот нете, например. Но есть другой класс систем. Например, возьмем Oracle с его встроенным PL/SQL. На этом языке можно писать хранимые процедуры и так называемые модули (наборы объявлений и процедур). Все это хранится в базе данных, Oracle отслеживает зависимости между процедурами/модулями. При изменении какого-либо объекта Oracle инвалидирует, а затем перекомпилирует его и зависимые от него объекты.
Так вот, во-первых, более мелкая гранулярность с точки зрения зависимостей могла бы в некоторых слуаях предотвратить циклические зависимости. Понятно, что если несколько модулей связаны циклической зависимостью, то перекомпилировать их можно только все вместе. А на это необходимо, как минимум, большое количество памяти на сервере (где и происходит перекомпиляция в случае Oracle). А разбивать на "правильные" модули систему никто не будет, потому что, бизнес логику пишут прикладники, которые хотят работать в высокоуровневой среде, которая не заставляет их заниматься всякой фигней.
Во-вторых, часто бывает, что изменения (обычно небольшие) необходимо внести прямо сейчас, т.е. в работающую систему. Oracle, естественно, не нужно останавливать, чтобы изменить хранимую процедуру. Поэтому, при запуске процедуры блокируются. Ну и естественно заблокированную процедуру изменить нельзя. Но также нельзя изменить и другие процедуры, от которых зависит запущенная. Поэтому, чем меньше зависимостей, тем больше шанс того, что мы сумеем сделать необходимые изменения без выгоняния пользователей из системы.
Но, Oracle, это СУБД, и в нем обычно не пишут много логики. А вот если перенести аналогию на сервер приложений...
Здравствуйте, Дарней, Вы писали:
Д>Расплатой за что является на порядок возросшая работа при загрузке программы в память.
Ерунда какая. Грубо говоря, надо пробежаться по всем импортируемым объектам и сравнить для каждого из них два целых числа — фактический finger-print с ожидаемым.
Здравствуйте, Дарней, Вы писали:
Д>Я — вижу. Еще вопросы есть?
Если разница есть, то не все константы можно заменить на параметры, значит и не нужно приводить это как доказательство своей правоты.
То что в .Net это откровенная дырка, ясно как божий день. Стоят затраты на ее закрытие получающейся выгода или нет — это второй вопрос. Но это, как минимум, некрасиво. Особенно для среды со всяческими type-safe'ами.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Ерунда какая. Грубо говоря, надо пробежаться по всем импортируемым объектам и сравнить для каждого из них два целых числа — фактический finger-print с ожидаемым.
Или не числа, а там например, строки . Хотя дела это не меняет.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Ерунда какая. Грубо говоря, надо пробежаться по всем импортируемым объектам и сравнить для каждого из них два целых числа — фактический finger-print с ожидаемым.
Просто сядь и сравни два числа — среднее количество сборок в крупном проекте и количество объектов в том же проекте. Разница даже не на порядок, а на несколько порядков.
Ну как, есть разница?
Здравствуйте, Дарней, Вы писали:
Д>Просто сядь и сравни два числа — среднее количество сборок в крупном проекте и количество объектов в том же проекте. Разница даже не на порядок, а на несколько порядков.
Сравни время, которое необходимо для проверки версии для класса и время, необходимое для построения таблицы виртуальных методов для этого же класса. А еще прибавь время, необходимое на JIT компиляцию. Проверка версии и одного процента не займет.
Здравствуйте, stalcer, Вы писали:
S>Если разница есть, то не все константы можно заменить на параметры, значит и не нужно приводить это как доказательство своей правоты.
Приведи хотя бы один пример, когда константу нельзя вынести в параметр конфигурации, но при этом есть необходимость заменять значение этой константы методом перекомпиляции и подмены всей сборки.
Ась?
S>То что в .Net это откровенная дырка, ясно как божий день. Стоят затраты на ее закрытие получающейся выгода или нет — это второй вопрос. Но это, как минимум, некрасиво. Особенно для среды со всяческими type-safe'ами.
Не дырка, а всего лишь кривоватый дизайн (как и вообще всё, что касается констант в CLI . Но это уже отдельный вопрос, да и в обероне нормальных конастант тоже нет, если не ошибаюсь ). Тем не менее, "дырка" при необходимости обходится безо всякого труда. Приводить это в качестве главного (и единственного) аргумента превосходства оберона над CLI — странновато выглядит, не правда ли?
Здравствуйте, stalcer, Вы писали:
S>Сравни время, которое необходимо для проверки версии для класса и время, необходимое для построения таблицы виртуальных методов для этого же класса. А еще прибавь время, необходимое на JIT компиляцию. Проверка версии и одного процента не займет.
Ну ладно, допустим, что это не важно.
Тогда, в одном случаем мы имеем контроль версий интерфейсов и реализаций, в другом — контроль версий только интерфейсов, но с меньшей гранулярностью. В общем случае, размен далеко не равноценный, хотя в некоторых (достаточно редких) случаях имеет смысл.
Здравствуйте, Дарней, Вы писали:
Д>Приведи хотя бы один пример, когда константу нельзя вынести в параметр конфигурации, но при этом есть необходимость заменять значение этой константы методом перекомпиляции и подмены всей сборки.
В процессе разработки, например. У любой константы я могу захотеть изменить значение и при этом надеяться на правильную перекомпиляцию.
Д>Не дырка, а всего лишь кривоватый дизайн (как и вообще всё, что касается констант в CLI . Но это уже отдельный вопрос, да и в обероне нормальных конастант тоже нет, если не ошибаюсь ). Тем не менее, "дырка" при необходимости обходится безо всякого труда. Приводить это в качестве главного (и единственного) аргумента превосходства оберона над CLI — странновато выглядит, не правда ли?
Да здесь и не идет разговора типа .Net vs Оберон. Эти две среды сравниваются только в контексте обсуждаемого вопроса, а не вообще. Поэтому и аргумент получается единственный.
Мне лично интересен сам подход, имхо, теоретически более правильный, дающий меньше "лишних" зависимостей.
Здравствуйте, stalcer, Вы писали:
S>В процессе разработки, например. У любой константы я могу захотеть изменить значение и при этом надеяться на правильную перекомпиляцию.
static readonly
S>Да здесь и не идет разговора типа .Net vs Оберон. Эти две среды сравниваются только в контексте обсуждаемого вопроса, а не вообще. Поэтому и аргумент получается единственный.
идет, идет. Личность автора ветки это гарантирует
S>Мне лично интересен сам подход, имхо, теоретически более правильный, дающий меньше "лишних" зависимостей.
Но не дающий контроля версий реализации. Нет уж, спасибо, не надо нам таких пирогов
Здравствуйте, Дарней, Вы писали:
Д>Тогда, в одном случаем мы имеем контроль версий интерфейсов и реализаций, в другом — контроль версий только интерфейсов, но с меньшей гранулярностью. В общем случае, размен далеко не равноценный, хотя в некоторых (достаточно редких) случаях имеет смысл.
На самом деле здесь две проблемы — перекомпиляция, т.е. автоматическое определение необходимости перепроверки и пересоздания модуля из его исходных текстов и, так называемая проблема dll hell. Вовсе не обязательно решать их одним механизмом.
При разработке мне эта подпись или strong name (или что там еще может быть) вовсе не нужны. А вот при выпуске релиза, да: запускаешь утилитку, она все подписывает (или не все, а только измененные сборки).
Здравствуйте, Дарней, Вы писали:
Д>static readonly
Ты там не ходи, ты здесь ходи. А то снег башка попадет — совсем мертвый будешь .
Д>Но не дающий контроля версий реализации. Нет уж, спасибо, не надо нам таких пирогов
Контроль версий и определение необходимости перекомипиляции — это две разные вещи
Здравствуйте, stalcer, Вы писали:
S>На самом деле здесь две проблемы — перекомпиляция, т.е. автоматическое определение необходимости перепроверки и пересоздания модуля из его исходных текстов и, так называемая проблема dll hell. Вовсе не обязательно решать их одним механизмом.
S>При разработке мне эта подпись или strong name (или что там еще может быть) вовсе не нужны. А вот при выпуске релиза, да: запускаешь утилитку, она все подписывает (или не все, а только измененные сборки).
Разумно. Но, насколько я понял, в обероне этот механизм — единственный.
Здравствуйте, Дарней, Вы писали:
Д>Приведи хотя бы один пример, когда константу нельзя вынести в параметр конфигурации, но при этом есть необходимость заменять значение этой константы методом перекомпиляции и подмены всей сборки. Д>Ась?
А что это Вы именно к константам привязались так сильно. Я их только для примера привел. Вместо них можно рассматривать какие угодно другие экспортируемые объекты. Например, взяли и в импортируемом модуле поменяли сигнатуру одной процедуры. Ясное дело, что те модули которые эту процедуру не использовали перекомпилировать не надо.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>А что это Вы именно к константам привязались так сильно. Я их только для примера привел. Вместо них можно рассматривать какие угодно другие экспортируемые объекты. Например, взяли и в импортируемом модуле поменяли сигнатуру одной процедуры. Ясное дело, что те модули которые эту процедуру не использовали перекомпилировать не надо.
А чего это ты к перекомпиляции привязался так сильно? Совершенно очевидно, что контроль необходимости перекомпиляции — это далеко не самый важный аспект компонентой системы.
Здравствуйте, Дарней, Вы писали:
Д>А чего это ты к перекомпиляции привязался так сильно? Совершенно очевидно, что контроль необходимости перекомпиляции — это далеко не самый важный аспект компонентой системы.
Наоборот. Это самый важный аспект. Замена компонента системы очень проста — она сводится к замене соответствующего модуля (DLL-файла) на другой. Для того чтобы не нарушилась целостность системы, она сама должна понимать может ли она работать с новым модулем или нет. При этом вполне может оказаться, что система может работать с данным модулем лишь частично. Например, если в новом модуле какая-то процедура имеет другую сигнатуру, то та часть системы, которая эту процедуру не использует может продолжать спокойно работать с этим новым модулем. Та часть системы, которая хотела использовать ту процедуру, работать с новым модулем не должна (да и просто не сможет).
Здравствуйте, Сергей Губанов, Вы писали:
Д>>А чего это ты к перекомпиляции привязался так сильно? Совершенно очевидно, что контроль необходимости перекомпиляции — это далеко не самый важный аспект компонентой системы.
СГ>Наоборот. Это самый важный аспект.
Основная задача компонентной модели — построение программы из готовых бинарных блоков. Которая, действительно, должна работать. По крайней мере, очень желательно
Но "должна работать" и "должна компилироваться" — это две совсем разные вещи.
Здравствуйте, Дарней, Вы писали:
СГ>>Наоборот. Это самый важный аспект.
Д>Основная задача компонентной модели — построение программы из готовых бинарных блоков. Которая, действительно, должна работать. По крайней мере, очень желательно Д>Но "должна работать" и "должна компилироваться" — это две совсем разные вещи.
Да, натурально разные вещи. И что? Каков из этого вывод-то должны сделать читатели Вашего сообщения?
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Да, натурально разные вещи. И что? Каков из этого вывод-то должны сделать читатели Вашего сообщения?
Процитирую еще раз.
Д>>А чего это ты к перекомпиляции привязался так сильно? Совершенно очевидно, что контроль необходимости перекомпиляции — это далеко не самый важный аспект компонентой системы.
СГ>Наоборот. Это самый важный аспект.
Вывод из этого следует, что самый важный аспект компонетной модели — это контроль версий типов во время выполнения программы, а не во время компиляции.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Да, натурально разные вещи. И что? Каков из этого вывод-то должны сделать читатели Вашего сообщения?
Д>Процитирую еще раз.
Д>>>А чего это ты к перекомпиляции привязался так сильно? Совершенно очевидно, что контроль необходимости перекомпиляции — это далеко не самый важный аспект компонентой системы.
СГ>>Наоборот. Это самый важный аспект.
Д>Вывод из этого следует, что самый важный аспект компонетной модели — это контроль версий типов во время выполнения программы, а не во время компиляции.
А я, наконец-то, понял, Вы говорите, что слова "контроль версий типов во время выполнения программы" и слова "контроль необходимости перекомпиляции" обозначают разные вещи. Естественно это так.
Я то всё время, говоря об инвалидации модулей-клиентов одновременно добавлял еще одну фразу: "а значит их нужно перекомпилировать". Естественно, что можно было эту вторую фразу не добавлять, а просто говорить об инвалидации модулей-клиентов. Теперь Ваше сообщение стало мне понятно.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Дарней, Вы писали:
Д>>А чего это ты к перекомпиляции привязался так сильно? Совершенно очевидно, что контроль необходимости перекомпиляции — это далеко не самый важный аспект компонентой системы.
СГ>Например, если в новом модуле какая-то процедура имеет другую сигнатуру...
Такого быть не должно. На этапе компиляции должна отслеживатся обратная совместимость и уже существующие сигнатуры не должны изменятся или удалятся. Только добавление новых.
Здравствуйте, Kluev, Вы писали:
K>Такого быть не должно. На этапе компиляции должна отслеживатся обратная совместимость и уже существующие сигнатуры не должны изменятся или удалятся. Только добавление новых.
Это как это? Мой модуль — как хочу так его и изменяю. К тому же это невозможно технически. Ведь компилятору (и автору модуля тоже) не известны модули-клиенты (да и их количество ни чем не ограничено), а известны только импортируемые модули.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>А я, наконец-то, понял, Вы говорите, что слова "контроль версий типов во время выполнения программы" и слова "контроль необходимости перекомпиляции" обозначают разные вещи. Естественно это так.
СГ>Я то всё время, говоря об инвалидации модулей-клиентов одновременно добавлял еще одну фразу: "а значит их нужно перекомпилировать". Естественно, что можно было эту вторую фразу не добавлять, а просто говорить об инвалидации модулей-клиентов. Теперь Ваше сообщение стало мне понятно.
Теперь осталось еще понять, что даже если тип не изменился, но изменились типы, от которых он зависит — то тип все равно должен считаться инвалидированным.
Плюс к этому надо учитывать неявные зависимости от других типов через совместно используемые данные.
Здравствуйте, Дарней, Вы писали:
Д>Теперь осталось еще понять, что даже если тип не изменился, но изменились типы, от которых он зависит — то тип все равно должен считаться инвалидированным.
Это всё, естественно, учитывается.
Д>Плюс к этому надо учитывать неявные зависимости от других типов через совместно используемые данные.
А вот это уже будет лишний двойной учет. Данные — это экспортируемая переменная. Если она достаточно сильно изменена, то импортирующий ее модуль уже инвалидируется. А раз он и так уже инвалидирован, то больше не надо искать других причин для его инвалидации, достаточно одной причины.
Здравствуйте, Сергей Губанов, Вы писали:
Д>>Теперь осталось еще понять, что даже если тип не изменился, но изменились типы, от которых он зависит — то тип все равно должен считаться инвалидированным.
СГ>Это всё, естественно, учитывается.
Описаний того, как это происходит, я не видел.
СГ>Данные — это экспортируемая переменная. Если она достаточно сильно изменена, то импортирующий ее модуль уже инвалидируется.
НЕ экспортируемая переменная. Внутренняя переменная, которая совместно используется несколькими типами в пределах импортированной сборки.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Kluev, Вы писали:
K>>Такого быть не должно. На этапе компиляции должна отслеживатся обратная совместимость и уже существующие сигнатуры не должны изменятся или удалятся. Только добавление новых.
СГ>Это как это? Мой модуль — как хочу так его и изменяю. К тому же это невозможно технически. Ведь компилятору (и автору модуля тоже) не известны модули-клиенты (да и их количество ни чем не ограничено), а известны только импортируемые модули.
Тогда никто кроме тебя им пользоватся и не будет. А хочешь делать компонент для использования в других программах обеспечь обратную совместимость. Или делай несовместимые версии с разными именами.
СГ>К тому же это невозможно технически
Что? невозможно обеспечить обратную совместимость? Это легко делается даже в с. старые сигнатуры не меняй, новые добавляй. Все будет работать
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Сергей Губанов, Вы писали:
Д>>>Теперь осталось еще понять, что даже если тип не изменился, но изменились типы, от которых он зависит — то тип все равно должен считаться инвалидированным.
СГ>>Это всё, естественно, учитывается.
Д>Описаний того, как это происходит, я не видел.
Так увидьте! Вы ту диссертацию (ссылка №8) уже скачали? Исходные коды Блэкбокса уже посмотрели?
СГ>>Данные — это экспортируемая переменная. Если она достаточно сильно изменена, то импортирующий ее модуль уже инвалидируется.
Д>НЕ экспортируемая переменная. Внутренняя переменная, которая совместно используется несколькими типами в пределах импортированной сборки.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Так увидьте! Вы ту диссертацию (ссылка №8) уже скачали? Исходные коды Блэкбокса уже посмотрели?
у меня просто нет на это время. Точнее, овчинка не стоит выделки — и так видно, что оберон слишком плохо продуман. Хотя какие-то хорошие идеи там возможно и есть.
СГ>Я не понял о чем Вы.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Для опровержения Вашего заявления, здесь список защищенных по оберонам и оберон-системам диссертаций/книг/публикаций. Все они очень хорошо продуманы.
Это мы уже слышали, начинать бесплодный спор сначала у меня желания нет.
Поэтому я просто скажу — как практик, я не считаю эту систему пригодной для широкого применения. Точка.
. Но это уже отдельный вопрос, да и в обероне нормальных конастант тоже нет, если не ошибаюсь ). Тем не менее, "дырка" при необходимости обходится безо всякого труда. Приводить это в качестве главного (и единственного) аргумента превосходства оберона над CLI — странновато выглядит, не правда ли?
