Если можно использовать продуманный способ расширения — используем.
Если нет, то:
форк;
модификация на основе x;
И если с форком все понятно, то модификация скорее всего будет основывается на конкретной фиксированной мажорной версии. Хорошо это или плохо уже другой вопрос, форк тоже поддерживать придется.
В случае модификации первоначальная библиотека теряет независимость и становится лишь частью новой. А с приватными классами это невозможно. Это как если бы при работе с форком вы бы увидев private метод говорили: «Этот метод нельзя редактировать, приватный же.»
Да, для идеального результата лучше форк, наверное. Но так и ddd можно везде применять, только смысла от этого не прибавится.
В установке нет ничего сложного, кроме разбиения дисков. Что там вообще и как будет разбиваться — не ясно. В винде по крайней мере пишут названия дисков и лишнее сложно удалить.
Ну и как всегда сложности установки рядом с виндой.
Мне вот не понятно ставить ли артикль в предложении. Предложение — подсказка к input. В оригинале стоит the.
Enter a title for [a, the] checklist pdf
И какая тут логика, мы что, знаем какой именно имеется ввиду checklist? Да нет, его еще не существует, имеется ввиду скорее абстрактный pdf-документ который получится исходя из этих настроек.
И вот так всегда. В теории все просто: a — общее, ед; the — частное, ед. Но на практике — как всегда.
Заметил что самые качественные продукты — массовые и в средней ценовой категории. А топовые решения иногда могут иметь больше ошибок/багов чисто из-за небольшой популярности.
Наверное, утуб лучше не брать в сравнения. Не знаю что они сделали с видеоплеером, но это стало тормозить.
В вашем случае легче переустановить винду :)
Наверное, есть несколько идеальных библиотек где все заложено и продумано, но остальные часто не позволяют этого.
Могу привести пример magento 2 с ее системой плагинов: методы protected & private не поддаются переопределению или дополнению через плагины (private classes in RFC) потому что так задумано. Но разработчики не могут предусмотреть все случаи использования и иногда private для метода — ошибка, и тогда приходится переопределять весь метод или даже класс (это fork) который может сломаться при последующих обновлениях.
Вообще, идеальные компоненты с отдельными интерфейсами и реализацией — это будущее. Но правильно ли блокировать изменение реализации и применять soLid в этом случае — вопрос.
Гарантией выступает фиксация версий или даже версии. Да, это не хорошая практика, но для частного решения вполне подходит. Вот пример: rulerz, основывается на «hoa/ruler»: "~2.0". И вполне работает.
И да, если версия стала камнем преткновения, то можно переопределить ее через repositories и package.
Ну а если возникнет необходимость расширить библиотеку переписав некоторые части — велкам ту форк? Сейчас же можно написать свое решение «поверх» этой библиотеки не мучаясь с поддержкой форков и т.д.
Как бы да, идея хорошая, но не без недостатков.
А у них не особо отличается цена, поэтому. Ну и бренд конечно полезен, но чтобы пользоваться без оглядки на условия — это проблема не в бренде.
И да, мелких букв у них нет. Куча условий есть, да. Но на каждые потребности можно найти удобный тариф.
Если можно использовать продуманный способ расширения — используем.
Если нет, то:
И если с форком все понятно, то модификация скорее всего будет основывается на конкретной фиксированной мажорной версии. Хорошо это или плохо уже другой вопрос, форк тоже поддерживать придется.
В случае модификации первоначальная библиотека теряет независимость и становится лишь частью новой. А с приватными классами это невозможно. Это как если бы при работе с форком вы бы увидев private метод говорили: «Этот метод нельзя редактировать, приватный же.»
Да, для идеального результата лучше форк, наверное. Но так и ddd можно везде применять, только смысла от этого не прибавится.
Ну и как всегда сложности установки рядом с виндой.
.
Не уверен что ваша теория верная.
И какая тут логика, мы что, знаем какой именно имеется ввиду checklist? Да нет, его еще не существует, имеется ввиду скорее абстрактный pdf-документ который получится исходя из этих настроек.
И вот так всегда. В теории все просто: a — общее, ед; the — частное, ед. Но на практике — как всегда.
Проект для других целей скорее.
В вашем случае легче переустановить винду :)
Могу привести пример magento 2 с ее системой плагинов: методы protected & private не поддаются переопределению или дополнению через плагины (private classes in RFC) потому что так задумано. Но разработчики не могут предусмотреть все случаи использования и иногда private для метода — ошибка, и тогда приходится переопределять весь метод или даже класс (это fork) который может сломаться при последующих обновлениях.
Вообще, идеальные компоненты с отдельными интерфейсами и реализацией — это будущее. Но правильно ли блокировать изменение реализации и применять soLid в этом случае — вопрос.
И да, если версия стала камнем преткновения, то можно переопределить ее через repositories и package.
Как бы да, идея хорошая, но не без недостатков.
А новую версию лучше все же разрабатывать отдельно.
И да, мелких букв у них нет. Куча условий есть, да. Но на каждые потребности можно найти удобный тариф.