Встречаем PHP 8 вместе: советы по обновлению, мнения за и против и интервью с ключевыми разработчиками +32
Разработка веб-сайтов, PHP, Блог компании Конференции Олега Бунина (Онтико), Блог компании Skyeng
У PHP отличное сообщество. Пандемия отобрала у нас митапы и конференцию, но мы можем собраться 25 ноября вечером в онлайне на:
- доклад «PHP 8: юзерленд» — нескучный обзор с примерами и рекомендациями,
- дискуссию о развитии языка,
- и сессию Q&A с Никитой Поповым (вопросы соберем по ходу эфира).
- UPD. К стриму также присоединится Дмитрий Стогов
Для участия достаточно
зарегистрироваться, это бесплатно. А пока есть время, мы попросили ребят, которые придут в трансляцию, вспомнить, за что они любили и не любили предыдущие версии языка.
Роман pronskiy Пронский — автор PHP-дайджестов и главный по маркетингу в PhpStorm. Соведущий нашего митапа
— Что было самым крутым в PHP 5?
— Неймспейсы, оператор goto ( ?° ?? ?°)
— А самым ужасным и вредным?
— Трейты.
— Когда PHP 6 не увидел свет, ты…
— Искал свою первую работу, связанную с PHP.
— Самое крутое в PHP 7?
— Zend Engine 3 — производительность!
— А самое бесполезное в 7-ке?
— Не помню ничего такого.
Александр SamDark Макаров — соавтор Yii3, главный по программе PHP Russia. Соведущий нашего митапа
— Что было самым крутым в PHP 5?
— Zend Engine 2. Нормальное ООП в сравнении с PHP 4 + много классных фич в промежуточных релизах.
— А самым ужасным?
— Ничего прям ужасного не вспомню.
— Когда PHP 6 не увидел свет, ты…
— В общем-то, не заметил этого :) Но потом, когда вчитался, понял, какой объём работ был выкинут — и насколько это должно быть обидно.
— Самое крутое в PHP 7?
— Скорость, типизация, ??, анонимные классы.
— А самое бесполезное в 7-ке?
— Семёрка хорошая.
Валентин vudaltsov Удальцов — автор телеграм-канала «Пых», активный контрибьютор в Symfony
— Что было самым крутым в PHP 5?
— То, что больше не снится мне в страшных снах.
— А самым ужасным?
— trait
— Когда PHP 6 не увидел свет, ты…
— Перешёл на QBasic.
— Самое крутое в PHP 7?
— ??=
— А самое бесполезное в 7-ке?
— trait.
— Что было самым крутым в PHP 5?
— Самое крутое, что он был вообще. Без него бы не было современных версий.
— А самым вредным?
— Пятерка была разной: между 5.6 и 5.0 скорее больше различий, чем чего-то общего. Язык изменился неузнаваемо. Лично для меня, наверное, самым вредным стало то, что длина int зависит от разрядности операционной системы.
— Когда PHP 6 не увидел свет, ты…
— Хотел скупить все книги по PHP 6, которые успели издать.
— Самое крутое в PHP 7?
— NG.
— А самое бесполезное в 7-ке?
— Когда-то считал бесполезными анонимные классы. Теперь так не считаю.
p.s. Стрим организован совместными усилиями Онтико (PHP Russia), devrel-команды Skyeng и проекта PHP Point. Отдельное спасибо Алисе
alyssashch Мартыновой из ростовского ИТ-сообщества RnD Tech за помощь с сайтом митапа.
А расскажите, за что трейты так не любят? Использовал один раз в жизни и давно, но тогда пригодились..
По факту это сокрытие проблемы с copy-paste. Выглядит более-менее, а в действительности всё может быть плохо.
Возможно, из-за того, что они не вписываются в концепцию SOLID, да и вообще могут поломать всё в неправильных руках (см. Deathly Diamond of Death)
Если рассматривать трейты как дефолтную реализацию интерфейса, то выглядят ничего так.
Главное в трейте опираться только на поля, которые в нем же и объявлены. Ну или на методы (в том числе и абстрактные) этого же трейта
В функциональных тестах трейты бывают очень полезны. Там часто нужно протестировать все варианты нескольких признаков. И через композицию это очень красиво решается.
Еще с помощью трейтов можно инжектить часто используемые зависимости в через сеттер. Это уже больше похоже на черную магию, но сколько лишнего кода с ее помощью можно убрать. :)
Плохо, когда трейты используются как альтернатива сервисам. Это усложняет понимание кода.
Трейты очень легко использовать во вред, когда вместо качественной декомпозиции, вырывают куски кода в своеобразный include (чем трейт в некоторой степени и является). К тому же трейты и интерфейсы, имхо, это костыль вместо полноценного множественного наследования, в которое PHP не смог, к сожалению.
У множественного наследования свои проблемы, которые интерфейсы с трейтами и решают.
Можно поподробнее?
Ромбовидное наследование.
Проблема при этом имеет решение.
Ну да, и одно из них это отказ от множественного наследования и применение трейтов. У них прямо в документашке про это написано.
Но не факт, что лучшее ;)
Это, наверное, комментарий о том, что любят за то, что так не должно быть.
Есть система с главным объектом, в котором вся работа, и под-объектом, в котором много более специфичной работы. Оказалось, что третий объект, доступный в главном объекте, нужен также и в том под-объекте. Под-объект создаётся ещё в конструкторе главного объекта, с помощью красивой магии контейнера Symfony Dependency Injection. Согрешил душой, и вместо того, чтобы перехреначить это всё, вынес третий объект в трэйт для главного и для под-объекта и сделал его синглтоном. За этот хак до сих пор ужасно стыдно, но профит был просто шикарный. Дело в том, что с точки зрения DDD было логично, чтобы тот трэйтнутый объект был доступен везде, где можно, так что на сопровождаемость системы эффект хака был нулевой. В общем, хоть я и люблю Perl, но PHP тоже хорош, есть где развернуться при необходимости. Анонимные классы тоже, кстати, весьма хороши! :)
Ни разу не было необходимости в анонимных классах. Зачем они могут понадобиться, например?
Я в тестировании использовал.
Это, наверное, не столько вопрос необходимости, сколько локального удобства. Был случай, когда был нужен просто безымянный объект для передачи по SOAP. Были свойства, которые в этом объекте нужны всегда, а были такие, которые нужно добавлять по условию, условий несколько. Я пошёл таким путём: в месте перед формированием и отправкой сообщения проверяются условия, создаётся ветвление, в каждой ветке которого инициализируется анонимный класс, который использует базовый трэйт (свойства, которые нужны всегда) и трэйты с условными свойствами. В результате, с одной стороны, SOAP API всегда получал кошерный объект, имеющий только необходимые свойства, а с другой — логика производства значений этих свойств была инкапсулирована под говорящими именами трэйтов с удобствами конструктора, приватных методов и поддержкой IDE. Можно, наверное, было сделать и по-другому, но, как обычно, всё должно быть готово ещё вчера, времени на глубокие размышления нет. Впрочем, поддерживать и расширять эту конструкцию было вполне удобно.
Передам куда следует :)
Считаю трейты одним из самых крутых фич php, очень не хватает в typescript такой же удобной реализации, есть миксины, но они не очень удобны
++ главное уметь их готовить. Очень часто использую их как блоки из которых собираю DTO запросов, а в сочетании с интерфейсами — вообще прекрасно.