В связи с соседней ветке, хотелось бы придти к общему мнению насчёт дополнительных зависимостей.
На данный момент есть одна для .NET Core/Standard и для зависимости старых версий .NET.
Предлагаю разделить проблему на две:
Внешние зависимости для .NET 4.5 и выше.
На данный момент нет никаких проблем с этим кроме .NET Core/Standard с одной зависимостью.
Тут либо обойти для них через рефлексию либо оставить.
Так как .NET Core/Standard всё вынесено в пакеты и так, достаточно просто требовать наименьшую версию пакета. (уже сделано)
Внешние зависимости для .NET 4.0 и ниже.
Здесь вариантов я вижу тоже два:
Либо тащить всё в CodeJam и получить конфликты имён.
Например если добавить интерфейс IReadOnlyDictionary, а проект имеет свой IReadOnlyDictionary получим приятные слова в адрес CodeJam.
Выделить часть CodeJam, которая требует внешние зависимости в отдельный пакет.
Так в проекте, использующий CodeJam, будет явно видно какая зависимость используется.
Мне кажется. этот вариант наиболее предпочтительный.
Здравствуйте, _NN_, Вы писали:
_NN>* Выделить часть CodeJam, которая требует внешние зависимости в отдельный пакет. _NN>Мне кажется. этот вариант наиболее предпочтительный.
А чем плох вариант с использованием готовой либы (theraot) для fw 4.5 и ниже?
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, _NN_, Вы писали:
_NN>>* Выделить часть CodeJam, которая требует внешние зависимости в отдельный пакет. _NN>>Мне кажется. этот вариант наиболее предпочтительный.
S>А чем плох вариант с использованием готовой либы (theraot) для fw 4.5 и ниже?
Ничем не плох, только нужно решить, что этот вариант нам подходит.
Проблемы будут в случае если проект использует свою реализацию слоя совместимости и не захочет переходить на Theraot или другую зависимость.
Хотя вполне возможно, что проблема надуманная и стоит решать только тогда, когда кто-нибудь попросит.
Ветка с Theraot в принципе готова к слиянию.
Если есть замечания, то самое время.
Здравствуйте, _NN_, Вы писали:
_NN>Выделить часть CodeJam, которая требует внешние зависимости в отдельный пакет.
Тем самым зависимости CodeJam заменяются на кучу зависимостей самого CodeJam. Я уж не говорю про тонну "удовольствия" гадать, какой именно из пакетов CJ тебе нужен.
Удобство CJ в том, что ты просто подключаешь пакет и сразу же получаешь комфортное и привычное окружение. А вот эта программистская привычка все нарезать на кирпичики и разложить по полочкам превращается в кучу лишних телодвижений.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Тем самым зависимости CodeJam заменяются на кучу зависимостей самого CodeJam. Я уж не говорю про тонну "удовольствия" гадать, какой именно из пакетов CJ тебе нужен.
Обычно все пакеты одной библиотеки имеет смысл обновлять совместно. Разве нет?
НС>Удобство CJ в том, что ты просто подключаешь пакет и сразу же получаешь комфортное и привычное окружение. А вот эта программистская привычка все нарезать на кирпичики и разложить по полочкам превращается в кучу лишних телодвижений.
Здесь как раз понятно за что пользователи платят за неудобства. Если ты такой хитровывернутый и хочешь пользоваться новыми фичами, но не хочешь/не имеешь возможности обновить версию фреймоврка, то немножко пострадай. Всё честно.
Если поддержку всего нового пихать в основную библиотеку, то проблемы получает тот, кто вообще как бы не при делах. Например, мне не нужен System.ValueTuple в моих проектах, я не использую FW 4.72, достаточно 4.52, тем не менее я получаю новую зависимость от двух разных пакетов, в которых к тому же разные версии этой зависимости. В результате чего имеем проблемы. Не-не-не. Давайте сами. Хотите новых фич в старом болоте, будьте добры сами разгребать это овнецо.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
НС>>Тем самым зависимости CodeJam заменяются на кучу зависимостей самого CodeJam. Я уж не говорю про тонну "удовольствия" гадать, какой именно из пакетов CJ тебе нужен. IT>Обычно все пакеты одной библиотеки имеет смысл обновлять совместно. Разве нет?
Я окончательно утерял логику в твоей борьбе с зависимостями.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, _NN_, Вы писали:
_NN>>Ветка с Theraot в принципе готова к слиянию. _NN>>Если есть замечания, то самое время.
S>Круть! Я пстараюсь завтра выкроить время и посмотреть. Огромное спасибо и
У меня тут свободное время было. Как же хорошо позаниматься чем-то отвлечённый от работы
Сегодня обновлю PR поддержкой .NET Core 1.0, 1.1, .NET Standard 1.6, 1.5.
Ниже версии поддерживать слишком накладно.
С этим .NET Standard так перемудрили, "нет слов — одни эмоции".
Таки добил это дело: пулл реквест.
Теперь спектр у CodeJam покрывает практически все сценарии.
Минимальные фреймворки: .NET Core 1.0, .NET Standard 1.5, .NET Framework 2.0.
Кому реально нужен .NET Standard 1.4 и ниже то пожалуйста добавляйте сами
Получилось практически всё внести, даже CodeJam.Blocks в Core и Standard.
Жду замечания и пожелания.
Если проблем не найдём, то объединю ветку с основной.
Здравствуйте, IT, Вы писали:
IT>Если поддержку всего нового пихать в основную библиотеку, то проблемы получает тот, кто вообще как бы не при делах. Например, мне не нужен System.ValueTuple в моих проектах, я не использую FW 4.72, достаточно 4.52, тем не менее я получаю новую зависимость от двух разных пакетов, в которых к тому же разные версии этой зависимости. В результате чего имеем проблемы. Не-не-не. Давайте сами. Хотите новых фич в старом болоте, будьте добры сами разгребать это овнецо.
Я так понимаю если бы изначально зависимость была бы от более низкой версии System.ValueType проблем бы не было ?
Установил минимально возможные версии всех зависимостей. Пришлось правда требовать более новую версию Theraot.
Всё собирается и тесты проходят.
Думаю можно вливать.
Что скажете ?
Если нам не помогут, то мы тоже никого не пощадим.
