Здравствуйте, Aikin, Вы писали:
A>Зачем приводить к конкретному типу? Накой это может понадобиться?
Интерфейс тоже является типом =) Я же не сказал "к классу". К интерфейсу.
Под понятием "тип" я имею в виду то, к чему можно применить typeof и что имеет описание и метаданные в некоторой сборке. Например IOSDModule — тип =)
Здравствуйте, Pavel M., Вы писали:
IB>>Сборка с контрактом и сборка с реализацией — две большие разницы. Сборки с реализацией может вообще не быть — никаких проблем это не вызовет. PM>Вызовет.
Какие?
PM>Нет описанного контракта, потому что интерфейс находился в сборке, которую убрали.
В чем проблема не убирать сборку с интерфейсом?
Как ты вообще без интерфейса работать собрался? Ровно с тем же успехом можно убрать сборку с IModule в варианте Stump-а и получим ту же хрень только в профиль.
PM>Есть статические референсы на сборку с описанием типа, для удобства работы, потому что работать полностью через рефлекшн крайне неудобно знаете ли (либо через универсальные методы DoAction(IDictionary...), при том, что так можно извернуться и работать типизировано, хоть и извращенно.
Вот тут я вообще не понял о чем ты.
PM>Хотя это и противоречит идеологии, видимо, раз такой спор возник =))
Что именно противоречит идеологии?
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Pavel M., Вы писали:
IB>Как ты вообще без интерфейса работать собрался? Ровно с тем же успехом можно убрать сборку с IModule в варианте Stump-а и получим ту же хрень только в профиль.
Интерфейс, например IOSDModule, описан в сборке с опциональной функциональностью , ее можно смело выбрасывать из системы, при этом система должна работать нормально IModule же — обязательная функциональность.
IB>Вот тут я вообще не понял о чем ты.
Еще раз писать то, что выше уже 3 раза писал, не буду.
IB>Что именно противоречит идеологии?
То, что сборки, используемые при компиляции, удаляются при рантайме.
Здравствуйте, Pavel M., Вы писали:
PM>Интерфейс, например IOSDModule, описан в сборке с опциональной функциональностью ,
В чем проблема описать его в той сборке, которая запрашивает опциональную или вообще отдельно?
PM>Еще раз писать то, что выше уже 3 раза писал, не буду.
Достаточно одного, но внятно.
PM>То, что сборки, используемые при компиляции, удаляются при рантайме.
Смотря какие сборки.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Pavel M., Вы писали:
PM>>Интерфейс, например IOSDModule, описан в сборке с опциональной функциональностью , IB>В чем проблема описать его в той сборке, которая запрашивает опциональную или вообще отдельно?
Как вы себе представляете это? Человек решил предоставить возможность другим модулям выводить OSD сообщение. Создал интерфейс IOSDModule и реализацию OSDModule в сборке OSDModule.dll, а Вы предлагаете его перенести в другую сборку... Это нелогично.
PM>>Еще раз писать то, что выше уже 3 раза писал, не буду. IB>Достаточно одного, но внятно.
Здравствуйте, Pavel M., Вы писали:
PM>Как вы себе представляете это?
Очень просто.
PM>Человек решил предоставить возможность другим модулям выводить OSD сообщение. Создал интерфейс IOSDModule и реализацию OSDModule в сборке OSDModule.dll, а Вы предлагаете его перенести в другую сборку... Это нелогично.
Нет, я предлагаю сделать так, что бы не другой модуль искал "А не умеет ли кто тут выводить OSD сообщение", а вот этот самый модуль говорил "Мужики, у меня тут IOSDModule есть, могу выводить — нуна кому-нибудь?" — тогда и проблем с отсутствием сборки не будет.
Вот это логично.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Pavel M., Вы писали:
IB>Вот это логично.
А сам модуль и не ищет. Он у ядра спрашивает, то есть, грубо говоря, у менеджера модулей, а есть ли у нас OSDModule или нету, но вопрос не в наличии модуля, а в использовании типов и исключении об отсутсвии сборки с описанием типа.
Мы уже победили, просто это еще не так заметно...
