Здравствуйте, IT, Вы писали:
IT>Здравствуйте, _NN_, Вы писали:
_NN>>Как закончу интеграцию с Theraot.Core, будет легко добавить поддержку.
IT>Это ещё одна зависимость?
Да. это слой совместимости для старых версий.
Для новых версий фреймворка зависимость будет не нужна конечно.
При чём эта будет единственной зависимостью, другие библиотеки как LinqBridge, TaskParallelLibrary будут не нужны.
Здравствуйте, _NN_, Вы писали:
IT>>Это ещё одна зависимость? _NN>Да. это слой совместимости для старых версий.
Можно же легко обойтись без каких-либо зависимостей.
_NN>При чём эта будет единственной зависимостью, другие библиотеки как LinqBridge, TaskParallelLibrary будут не нужны.
Одна уже есть — System.ValueTuple и она мне уже весь мозг высосала. Пришлось даунгрейдить её до определённой версии из-за конфликтов. Народ на проекте кто ржёт, кто матом орёт и грозиться "вынинуть найух этот твой CodeJam, задолбал он уже". А вы ещё зависимостей добавляете Убирать существующие надо, а не добавлять новые. CodeJam не тот проект, который ну никак не обойдётся без зависимостей.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, _NN_, Вы писали:
IT>>>Это ещё одна зависимость? _NN>>Да. это слой совместимости для старых версий.
IT>Можно же легко обойтись без каких-либо зависимостей.
Каким обоазом? Притащить весь код библиотек в CodeJam? _NN>>При чём эта будет единственной зависимостью, другие библиотеки как LinqBridge, TaskParallelLibrary будут не нужны.
IT>Одна уже есть — System.ValueTuple и она мне уже весь мозг высосала. Пришлось даунгрейдить её до определённой версии из-за конфликтов. Народ на проекте кто ржёт, кто матом орёт и грозиться "вынинуть найух этот твой CodeJam, задолбал он уже". А вы ещё зависимостей добавляете Убирать существующие надо, а не добавлять новые. CodeJam не тот проект, который ну никак не обойдётся без зависимостей.
Не проще ли в CodeJam просто обновить зависимость ?
Какое решение предлагается ?
Здравствуйте, _NN_, Вы писали:
IT>>Можно же легко обойтись без каких-либо зависимостей. _NN>Каким обоазом? Притащить весь код библиотек в CodeJam?
Если нужно весь, то можно притащить весь. Хотя это вряд ли понадобится.
_NN>Не проще ли в CodeJam просто обновить зависимость ?
Кому проще? Юзерам проще выкинуть это овно нахрен и предать анафеме криворуких девелоперов вместе с их поделками.
_NN>Какое решение предлагается ?
Предлагается убрать существующие зависимости и не добавлять новых без совсем уж крайней необходимости. А если такая необходимость возникнет, то всегда можно создать новый проект.
Но данный случай — это не та самая необходимость. Лучше уж не трогать ничего. Пусть не будет этой поддержки, хрен с ней, если не хватает тяму обойтись без дополнительных зависимостей.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, _NN_, Вы писали:
IT>>>Можно же легко обойтись без каких-либо зависимостей. _NN>>Каким обоазом? Притащить весь код библиотек в CodeJam?
IT>Если нужно весь, то можно притащить весь. Хотя это вряд ли понадобится.
В случае старых фреймворков понадобится.
Чем новее фреймворк тем меньше нужно.
_NN>>Не проще ли в CodeJam просто обновить зависимость ?
IT>Кому проще? Юзерам проще выкинуть это овно нахрен и предать анафеме криворуких девелоперов вместе с их поделками.
_NN>>Какое решение предлагается ?
IT>Предлагается убрать существующие зависимости и не добавлять новых без совсем уж крайней необходимости. А если такая необходимость возникнет, то всегда можно создать новый проект.
IT>Но данный случай — это не та самая необходимость. Лучше уж не трогать ничего. Пусть не будет этой поддержки, хрен с ней, если не хватает тяму обойтись без дополнительных зависимостей.
В таком случае библиотеку надо сделать только для последних версий .NET и никаких зависимостей не потребуется совсем.
Проблема в том, что не у всех есть счастье пользоваться последними версиями фреймворков.
Можно разделить библиотеку.
Будет
CodeJam с поддержкой только 4.8 и Core 3.0.
CodeJam.Legacy для более старых версий с дополнительными зависимостями
Здравствуйте, _NN_, Вы писали:
_NN>Проблема в том, что не у всех есть счастье пользоваться последними версиями фреймворков.
Например, у меня.
_NN>Можно разделить библиотеку.
Не надо ничего делить. Надо втащить для старых фреймворков код для совместимости в саму библиотеку, без всяких новых зависимостей. Работы на пол часа. Мы тут дольше это обсуждаем.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, _NN_, Вы писали:
_NN>>Проблема в том, что не у всех есть счастье пользоваться последними версиями фреймворков.
Наверное стоит определиться о какой версии идёт речь.
Для версий меньше 4.5 в любом случае в проекте будет слой совместимости и лучше если не будет дублирований имён и все будут пользоваться одной библиотекой.
Также для версий до 4.0 тащить весь System.Threading.Tasks в CodeJam мне кажется перебором.
Для 4.5 и выше на данный момент единственной зависимостью является System.ValueTuple последней версии.
Если код этой библиотеки втащить в CodeJam, то будет конфликт имён если проект использует зависимость на System.ValueTuple.
Мне кажется, тут проще синхронизировать версии.
IT>Например, у меня.
_NN>>Можно разделить библиотеку.
IT>Не надо ничего делить. Надо втащить для старых фреймворков код для совместимости в саму библиотеку, без всяких новых зависимостей. Работы на пол часа. Мы тут дольше это обсуждаем.
Вопрос сколько кода втаскивать и для каких старых фреймворков.
Можно втащить хоть всю библиотеку Theraot (LinqBridge, TaskParallelLibrary и т.д.) вместо зависимости и получить проблемы в других местах.
Здравствуйте, _NN_, Вы писали:
_NN>Для 4.5 и выше на данный момент единственной зависимостью является System.ValueTuple последней версии. _NN>Если код этой библиотеки втащить в CodeJam, то будет конфликт имён если проект использует зависимость на System.ValueTuple.
От System.ValueTuple нужно просто избавиться. У нас нет публичного API, который её использует. А без внутреннего использования можно как-нибудь обойтись.
_NN>Мне кажется, тут проще синхронизировать версии.
С кем синхронизировать? С юзерами, у которых в проектах полный зверинец из всех возможных версий? Они синхронизируют это очень просто — нахрен ваш CodeJam и всё.
IT>>Не надо ничего делить. Надо втащить для старых фреймворков код для совместимости в саму библиотеку, без всяких новых зависимостей. Работы на пол часа. Мы тут дольше это обсуждаем.
_NN>Вопрос сколько кода втаскивать и для каких старых фреймворков.
Сколько нужно столько и втаскивать. В linq2db как-то это получается и нет никаких проблем ни с какой совместимостью.
_NN>Можно втащить хоть всю библиотеку Theraot (LinqBridge, TaskParallelLibrary и т.д.) вместо зависимости и получить проблемы в других местах.
Каких, например?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, _NN_, Вы писали:
_NN>>Для 4.5 и выше на данный момент единственной зависимостью является System.ValueTuple последней версии. _NN>>Если код этой библиотеки втащить в CodeJam, то будет конфликт имён если проект использует зависимость на System.ValueTuple.
IT>От System.ValueTuple нужно просто избавиться. У нас нет публичного API, который её использует. А без внутреннего использования можно как-нибудь обойтись.
Если нет публичного API то достаточно иметь просто internal классы.
Не вижу проблем это исправить.
IT>Сколько нужно столько и втаскивать. В linq2db как-то это получается и нет никаких проблем ни с какой совместимостью.
Посыл я понял.
Таки нужно делить библиотеку тогда.
Скажем, CodeJam библиотека 0 зависимостей.
И например CodeJam.TaskParallelLibary расщиряющий TPL для .NET 3.5 на базе TaskParallelLibrary nuget-а.
Здравствуйте, IT, Вы писали:
_NN>>Можно втащить хоть всю библиотеку Theraot (LinqBridge, TaskParallelLibrary и т.д.) вместо зависимости и получить проблемы в других местах. IT>Каких, например?
При подключенгии второй библиотеки с теми же именами типов Type.GetType("") выдаст много чего интересного. В ту же степь — разные DI с локальным кэшем по Type.FullName.
Так что я — или за готовый слой, или за internal-типы.
P.S. Если есть проблемы с старыми фреймворками — давай issue с репро, бум чинить.
Здравствуйте, _NN_, Вы писали:
_NN>Если нет публичного API то достаточно иметь просто internal классы.
Вот оно в internal классах и используется.
_NN>Не вижу проблем это исправить.
Нужно исправить.
IT>>Сколько нужно столько и втаскивать. В linq2db как-то это получается и нет никаких проблем ни с какой совместимостью. _NN>Посыл я понял. _NN>Таки нужно делить библиотеку тогда. _NN>Скажем, CodeJam библиотека 0 зависимостей. _NN>И например CodeJam.TaskParallelLibary расщиряющий TPL для .NET 3.5 на базе TaskParallelLibrary nuget-а.
Делить тоже плохо. Особенно по такому пустяшному поводу. В данном случае я бы вообще убрал поддержку TPL для 4.0 и ниже. Но если уж кому-то нужно очень очень, тогда действительно можно отдельной сборкой, но при этом соблюсти структуру классов основной сборки, чтобы при переходе на новую версию можно было просто убрать референс из проекта.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, IT, Вы писали:
_NN>>>Можно втащить хоть всю библиотеку Theraot (LinqBridge, TaskParallelLibrary и т.д.) вместо зависимости и получить проблемы в других местах. IT>>Каких, например?
S>При подключенгии второй библиотеки с теми же именами типов Type.GetType("") выдаст много чего интересного. В ту же степь — разные DI с локальным кэшем по Type.FullName. S>Так что я — или за готовый слой, или за internal-типы.
Проблема тор то ясна.
Скажем для .NET 2.0 сейчас неподдерживаемый старый LinqBridge я хочу заменить на более поддерживаемую библиотеку.
Теперь придётся либо переключаться в своём проекте либо огрести конфликты имён из двух библиотек.
S>P.S. Если есть проблемы с старыми фреймворками — давай issue с репро, бум чинить.
CodeJam хочет ValueTuple 4.5.0, а проект использует другую версию, скажем 4.0.0.
Здравствуйте, IT, Вы писали:
IT>Делить тоже плохо. Особенно по такому пустяшному поводу. В данном случае я бы вообще убрал поддержку TPL для 4.0 и ниже. Но если уж кому-то нужно очень очень, тогда действительно можно отдельной сборкой, но при этом соблюсти структуру классов основной сборки, чтобы при переходе на новую версию можно было просто убрать референс из проекта.
У меня есть проект, требует 3.5, и хотелось бы иметь плюшки из CodeJam тоже.
Некоторые проекты вообще с 2.0.
Какие будут предложения ?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, _NN_, Вы писали:
_NN>>Если нет публичного API то достаточно иметь просто internal классы.
IT>Вот оно в internal классах и используется.
Если не считать защищённых членов публичных классов.
public class SuffixTreeBase
{
protected List<(int Start, int Length)> StringLocations { get; }
}
Здравствуйте, Sinix, Вы писали:
S>При подключенгии второй библиотеки с теми же именами типов Type.GetType("") выдаст много чего интересного. В ту же степь — разные DI с локальным кэшем по Type.FullName. S>Так что я — или за готовый слой, или за internal-типы.
А зачем нам такие же типы? Namespace будет другой, можно и имена типам другие дать, тем более, что все они как правило реализуются как расширения. К тому же их можно закатать под internal.
S>P.S. Если есть проблемы с старыми фреймворками — давай issue с репро, бум чинить.
Есть проблема с ненужными зависимостями.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, _NN_, Вы писали:
_NN>У меня есть проект, требует 3.5, и хотелось бы иметь плюшки из CodeJam тоже. _NN>Некоторые проекты вообще с 2.0. _NN>Какие будут предложения ?
Сделать отдельной либой. Так только ты один немножко страдать будешь. Но это нормальная плата за такие хотелки.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, _NN_, Вы писали:
_NN>>Если нет публичного API то достаточно иметь просто internal классы.
IT>Вот оно в internal классах и используется.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, _NN_, Вы писали:
_NN>>У меня есть проект, требует 3.5, и хотелось бы иметь плюшки из CodeJam тоже. _NN>>Некоторые проекты вообще с 2.0. _NN>>Какие будут предложения ?
IT>Сделать отдельной либой. Так только ты один немножко страдать будешь. Но это нормальная плата за такие хотелки.
Мне всё равно сколько зависимостей добавлять в конечный проект.
Там и так без проблем десяток собирается всякого разного.
Убирать существующие надо, а не добавлять новые. CodeJam не тот проект, который ну никак не обойдётся без зависимостей.
Если нам не помогут, то мы тоже никого не пощадим.
