Comments 28
Риалтайм тайпхинты в PhpStorm – что думаете?
Я бы отключил эту функцию. Мне не нравится текст в редакторе, который на самом деле отсутствует. Не нравится поведение курсора при клике на такие «фантомы».
Достаточно подсказки типа при Ctrl+Hover.
Я бы отключил эту функцию.
отключите, вам никто не мешает)
хотя соглашусь что фича сомнительная, так как если в коде реально от этого есть польза то есть вопрос к такому коду. Разве что вижу плюс в ситуациях, когда надо разобраться с типами в чем-то сложном, и хочется смотреть всю картину в целом а не только отдельные переменные. Но я бы предпочел это как отдельный режим отображения, который не включен по умолчанию.
я использую наверно процетов 20%
20% это уже не мало, либо вы преувеличили. Что до "остальное выкинуть" — не выйдет. У всех это разные 20%. Да и опять же, вы уверены что вы не пользуетесь какими-то фичами потому что они вам не нужны, или вы просто о них не знаете?)
20% это уже не мало, либо вы преувеличили.
не могу сказать что я знаю весь список фич и из них я использую 20%, скорее из тех что я знаю, я использую 20%
У всех это разные 20%
Без статистики нельзя делать такие выводы. По опыту в других областях, могу сказать, что люди далеко не уникальны в своем поведении. Безусловно, будут те кто пострадают, т.к. придется поставить процентный порог начиная, с которого фича будет считаться популярной.
[RFC] Namespace Visiblity for Class, Interface and Trait — Предлагается ввести модификаторы доступа для классов, интерфейсов и трейтов для ограничения использование по пространству имен:
Вот это нужная тема +++
первое что приходит на ум — билдеры. Второе — какие-то internal штуки которые хочется защитить от того, что бы их кто-то еще юзал (актуально если вы пишите библиотеки публичные).
Как бы да, идея хорошая, но не без недостатков.
велкам ту форк?
именно так. Иначе никакой гарантии что ваше "расширение" не сломается в следующем релизе.
И если под "расширением" вы подразумеваете extends — специально для все все классы с интерфейсами сделать final
И да, если версия стала камнем преткновения, то можно переопределить ее через repositories и package.
для того что бы автор библиотеки мог следовать semver, ему нужно понимать какие изменения ломают обратную совместимость а какие нет. То есть у разработчика должно быть понятие "публичный интерфейс".
Если возможность "отнаследоваться и переопределись" не была заложена как часть этого публичного интерфейса, тем более если классы или методы были отмечены тегом @internal, разработчик не должен воспринимать это дело как публичный интерфейс и его право ломать обратную совместимость в этом месте в пределах минорного релиза.
Ну и опять же относительно фиксации версий — вы можете зафиксировать конкретную версию. И что, уже обновляться никогда не будете? Если вы пользуетесь исключительно публичным API высока вероятность что обратная совместимость будет поддерживаться довольно продолжительный период.
Вот пример: rulerz, основывается на «hoa/ruler»: "~2.0". И вполне работает.
Как это относится к теме дискуссии? вопервых hoa/ruler в целом предоставяет точки расширения, и это является публичным интерфейсом этой библиотеки. Это в нее заложено было, а потому за обратной совместимостью там следят. Потому опять же не понимаю причем тут оно.
если версия стала камнем преткновения
не версия, а необходимость поддержания обратной совместимости. Мне как автору библиотеки выгодно по максимуму уменьшить варианты использования библиотеки, так как иначе я не могу предсказать кому я чего могу сломать. И даже тот факт что я выкладываю библиотеку с лицензией вида "если я вам чего сломаю — сами виноваты" — это не отменяет того факта что ломать кому-то чего-то просто так это не очень хорошая идея.
Если можно использовать продуманный способ расширения — используем.
Если нет, то:
- форк;
- модификация на основе x;
И если с форком все понятно, то модификация скорее всего будет основывается на конкретной фиксированной мажорной версии. Хорошо это или плохо уже другой вопрос, форк тоже поддерживать придется.
В случае модификации первоначальная библиотека теряет независимость и становится лишь частью новой. А с приватными классами это невозможно. Это как если бы при работе с форком вы бы увидев private метод говорили: «Этот метод нельзя редактировать, приватный же.»
Да, для идеального результата лучше форк, наверное. Но так и ddd можно везде применять, только смысла от этого не прибавится.
А с приватными классами это невозможно.
и это не мои проблемы если вы вдруг решили делать что-то что я не подразумевал когда делал библиотечку.
«Этот метод нельзя редактировать, приватный же.»
Если я форкнул библиотеку то скорее всего не для того что бы добавить в нее фичи которые мне нужны а что бы баг пофиксить. Иначе я не очень понимаю зачем использовать библиотеку которая не очень то мне подходит и при этом ее нельзя расширить.
Но так и ddd можно везде применять, только смысла от этого не прибавится.
Некорректное сравнение.
Также из вашего комментария хорошо виден еще 1 плюс: «переписав некоторые части» — если обсуждаемый rfc одобрят, то разработчик четко сможет контроллировать все точки расширения и свести к минимуму некорректные(по его мнению) варианты использования своей либы, инкапсулировав внутренню логику, что не позволит юзерам переписать что-то не то.
Ну а если вам нужно, как то переписать что-то, что разраб пометил как деталь внутренней реализации, то это 100% уже форк, так как ваше видение либы будет отличаться от видения автора, и по сути это уже самостоятельный проект, хоть и базирующийся на основе другого.
Могу привести пример magento 2 с ее системой плагинов: методы protected & private не поддаются переопределению или дополнению через плагины (private classes in RFC) потому что так задумано. Но разработчики не могут предусмотреть все случаи использования и иногда private для метода — ошибка, и тогда приходится переопределять весь метод или даже класс (это fork) который может сломаться при последующих обновлениях.
Вообще, идеальные компоненты с отдельными интерфейсами и реализацией — это будущее. Но правильно ли блокировать изменение реализации и применять soLid в этом случае — вопрос.
методы protected & private не поддаются переопределению
желание расширять функционал через наследование — плохое желание. В 90% случаев есть варианты лучше.
В системах где код — только встраиваемые модули, например, так не всегда получается.
Может просто не надо сферических коней обсуждать? приводите конкретные примеры (и если можно не магенту), которые можно обсудить. Иначе это разговор ниочем.
p.s. да, моя ситуация такова что я выбираю решения и проекты, и я целенаправлено не выбираю проекты с магенту и прочими вордпрессами ибо считаю это неверной стратегией развития и реюза кода. Однако не стоит думать что мне не приходится оставлять себе "точки расширения" или что я всегда могу их подобрать так что бы оно было на все случаи жизни. Всего наперед не узнаешь. Но вот либы форкать что бы фичи добавлять мне не приходилось (разве что как PR к этим либам).
PHP-Дайджест № 135 (9 – 23 июля 2018)