Идет время, проходят месяц-за-месяцем, год-за-годом, проводятся конференции, работают работу люди в Zend, пишутся какие-то статьи, давно уже вышел composer и появился репозиторий packagist, количество годных разработок на гитхабе растёт… И почему-то в каждой второй статье на хабре/реддите/… находится хотя бы один «оригинал» и «нон-конформист», познавший дзен computer science, который считает необходимым написать «пхп-говно».
Серьезно, и это на ресурсе, который создан для профессионалов и размещающий технически хорошие статьи…
Если вам прям так охота написать ваше ничем не аргументированное мнение, дойдите, пожалуйста, до ближайшего забора, и напишите на нём ваше мнение — там оно, возможно, хоть кому-то будет полезно, но не здесь.
Перестаньте, плиз, троллить и делать вбросы там, где это не приветствуется.
Простите, но в какой именно книжке пишут «не используйте его»?
Боюсь, что практика «категорически не использовать goto» есть только в структурном программировании, основным идеологом коей является Вирт и его последователи.
Остальные люди высказываются более осторожно: говорят, что без понимания «для чего» этот оператор использовать не стоит.
А в остальном, это вполне нормальный оператор, который иногда помогает упростить код или добавить микрооптимизаций.
З.Ы. за всю мою карьеру, мне этот оператор понадобился лишь 3 раза.
Увы, не оскорбил. Но хабр позиционируется как ресурс для профессионалов и культурных людей. А потому троллинг и вбросы тут не приветствуются. Если у вас есть мнение почему похапэ такой плохой, то есть 2 варианта: написать аргументированное мнение или не писать совсем.
Внесу небольшую поправку по поводу PSR Naming Conventions: это внутренний документ, регулирующий правила именования для самих PSR. То есть один из стандартов для публикуемых рекомендаций.
PSR Naming Conventions предназначен для разработчиков PSR и не оформлен сам как PSR, а потому он не является рекомендацией для нейминга теми проектами, которые используют PSR.
UPD. Впрочем как и Symfony Conventions — это, соответственно, тоже правила и конвенции, предназначенные для разработчиков и контрибьютеров Symfony
В хорошем направлении движетесь. Может, когда-нибудь, у вас и DI появится. Не исключаю, что самописный бо ни одна из имеющихся реализаций вам не подойдёт.
Однако, если когда-нибудь вы дойдёте до того, чтобы внедрять DI, то, плиз, не используйте его как сервис-локатор, но и не скатывайтесь в «инжектить всё». Некоторые вещи стоит использовать через классические статические фабрики.
Не передёргивайте пожалуйста. Определение данных и структур во время компиляции, JIT и lazy loading — это как путать тёплое с мягким. Совершенно разные технологии, предназначенные для разного и решающие разные задачи. Это во-первых.
Во-вторых, ваш тон и тон Алекса Леонова черезчур категоричен. Пожалуй, что стоило бы для начала разобраться в чём разница между const и define(). Какие есть плюсы и минусы. Пожалуй, лучше всего ответил на этот вопрос Никита Попов (один из разработчиков ядра PHP): https://stackoverflow.com/a/3193704
В третьих, так да, const определённо лучше, чем define хотя бы потому, что значение константы инлайнится (в пределах файла, где происходит определение константы) и лучше поддаётся оптимизации OpCache благодаря возможности константных вычислений во время компиляции, а не в рантайме, что, допустим, может привести к меньшему количеству опкодов и более эффективному использованию буфера interned strings (не знаю как правильно на русский перевести).
В-четвёртых, в свете реализованных некоторых SSA-оптимизаций конструкция const может (именно может, но не факт) работать опять-таки благодаря константным выражениям и как следствие раскрутки и слопыванию узлов AST.
В-пятых, постарайтесь не быть настолько категоричным и фанатичным. Это я отношу как к вам, так и к Алексу Леонову.
Ну это ваше личное мнение. А у кого недостатков нет? Не, ну серьёзно, кто-то когда-то начал собирать странности и особенности PHP, остальные подхватили и теперь такая мощная пропаганда, что PHP — гадость. Особенно радует, когда люди апеллируют к «фракталу плохого дизайна». Статье, написанной в мохнатые времена, когда в ходу была ещё версия 5.1, Laravel не сущестовал даже как проект, а Symfony был… ну не будем об этом.
Если вам не нравится этот язык, его экосистема и инфраструктура, ну не программируйте на нём. Делать вброс вида «php sucks», имхо, не стоит. Уж хотя бы обосновали бы мнение своим личным опытом, не опытом постороннего дяди.
Я искренне желаю вам получать удовольствие от работы с тем инструментом, который вам нравится и с которым готовы прожить остаток жизни (не сарказм) :)
Плохому танцору… Жизнь — боль. Нет во всех отношениях хорошего языка, везде есть проблемы. А ещё легаси для обратной совместимости, которое часто мешает.
Полностью согласен. Потому и написал, что правила стоит применять разумно и обоснованно. В том смысле, что не существует гайда «как делать правильно». Существует разумный подход под конкретную проблему.
В случае работы с небольшим данными лучше использовать иммутабельные структуры. Если работаешь с массивом в несколько миллионов UUID, то лучше использовать мутабельные, но аккуратно, поскольку накралдные расходы на копирование такого массива перевесят все плюсы от иммутибельности.
За парой исключений: во-первых, unset работает константное время, во-вторых он не приводит к копированию целого массива. За исключением ситуации, если дальше по коду происходит изменение $usersIds. В ином случае не вижу необходимости в потере производительности и дополнительному расходу памяти.
Все правила логичны и разумны, но их стоит применять обоснованно. И, в некоторых случае, как тут вполне можно использовать unset
if (!is_numeric($x) || $x != (int) $x) {
throw new TypeError(/* ... */);
}
$x = (int) $x;
То же самое можно сказать и про объекты:
if (!$x instanceof SomeClass) {
throw new TypeError(/* ... */);
}
И не более.
И да, вы правы: тайпхинты нужны для валидации типов аргументов. И не более.
Разница в том, что тайпхинт работает таки быстрее, чем «аналоги». И не более.
Серьезно, и это на ресурсе, который создан для профессионалов и размещающий технически хорошие статьи…
Если вам прям так охота написать ваше ничем не аргументированное мнение, дойдите, пожалуйста, до ближайшего забора, и напишите на нём ваше мнение — там оно, возможно, хоть кому-то будет полезно, но не здесь.
Перестаньте, плиз, троллить и делать вбросы там, где это не приветствуется.
Боюсь, что практика «категорически не использовать goto» есть только в структурном программировании, основным идеологом коей является Вирт и его последователи.
Остальные люди высказываются более осторожно: говорят, что без понимания «для чего» этот оператор использовать не стоит.
А в остальном, это вполне нормальный оператор, который иногда помогает упростить код или добавить микрооптимизаций.
З.Ы. за всю мою карьеру, мне этот оператор понадобился лишь 3 раза.
PSR Naming Conventions предназначен для разработчиков PSR и не оформлен сам как PSR, а потому он не является рекомендацией для нейминга теми проектами, которые используют PSR.
UPD. Впрочем как и Symfony Conventions — это, соответственно, тоже правила и конвенции, предназначенные для разработчиков и контрибьютеров Symfony
Однако, если когда-нибудь вы дойдёте до того, чтобы внедрять DI, то, плиз, не используйте его как сервис-локатор, но и не скатывайтесь в «инжектить всё». Некоторые вещи стоит использовать через классические статические фабрики.
Доклад хороший. Спасибо.
Во-вторых, ваш тон и тон Алекса Леонова черезчур категоричен. Пожалуй, что стоило бы для начала разобраться в чём разница между const и define(). Какие есть плюсы и минусы. Пожалуй, лучше всего ответил на этот вопрос Никита Попов (один из разработчиков ядра PHP): https://stackoverflow.com/a/3193704
В третьих, так да, const определённо лучше, чем define хотя бы потому, что значение константы инлайнится (в пределах файла, где происходит определение константы) и лучше поддаётся оптимизации OpCache благодаря возможности константных вычислений во время компиляции, а не в рантайме, что, допустим, может привести к меньшему количеству опкодов и более эффективному использованию буфера interned strings (не знаю как правильно на русский перевести).
В-четвёртых, в свете реализованных некоторых SSA-оптимизаций конструкция const может (именно может, но не факт) работать опять-таки благодаря константным выражениям и как следствие раскрутки и слопыванию узлов AST.
В-пятых, постарайтесь не быть настолько категоричным и фанатичным. Это я отношу как к вам, так и к Алексу Леонову.
Если вам не нравится этот язык, его экосистема и инфраструктура, ну не программируйте на нём. Делать вброс вида «php sucks», имхо, не стоит. Уж хотя бы обосновали бы мнение своим личным опытом, не опытом постороннего дяди.
Я искренне желаю вам получать удовольствие от работы с тем инструментом, который вам нравится и с которым готовы прожить остаток жизни (не сарказм) :)
В случае работы с небольшим данными лучше использовать иммутабельные структуры. Если работаешь с массивом в несколько миллионов UUID, то лучше использовать мутабельные, но аккуратно, поскольку накралдные расходы на копирование такого массива перевесят все плюсы от иммутибельности.
Все правила логичны и разумны, но их стоит применять обоснованно. И, в некоторых случае, как тут вполне можно использовать unset
2 2 + 2 * => (2+2) * 2
2 2 * 2 + => 2 * 2 + 2
И далее в коде не использовать обратные слеши.
То же самое можно сказать и про объекты:
И не более.
И да, вы правы: тайпхинты нужны для валидации типов аргументов. И не более.
Разница в том, что тайпхинт работает таки быстрее, чем «аналоги». И не более.