В выпуске: PHP 7.3 alpha 4, ReactPHP 1.0 LTS и другие релизы, свежее предложение «Namespace Visiblity for Class, Interface and Trait» из PHP Internals, ведеозаписи докладов и вебинаров, порция полезных инструментов, и многое другое.
Приятного чтения!
Новости и релизы
- PHP 7.3.0 alpha 4 — Последняя «альфа» в цикле. Первый бета-выпуск запланирован на 2 августа. К списку новых возможностей добавится недавно принятое предложение о введение новых функций
array_key_first()/array_key_last()для работы с массивами:
$array = ['a' => 1, 'b' => 2, 'c' => 3]; $firstKey = array_key_first($array); // 'a' $lastKey = array_key_last($array); // 'c'
Этап голосования прошло предложение Deprecations for PHP 7.3, в котором несколько возможностей объявлены устаревшими. Также устаревшими в PHP 7.3 будут объявлены константы нечувствительные к регистру.
Что касается предложения по типизированным свойствам, то его решено отложить до следующей версии, которой, вероятно, станет PHP 8.0. - Обновления всех актуальных веток PHP с исправлениями ошибок безопасности:
• PHP 7.2.8
• PHP 7.1.20
• PHP 7.0.31
• PHP 5.6.37
- PhpStorm 2018.2 Public Preview — Среди нововведений: обновленный интерфейс и поддержка touch bar, улучшенное автодополнение с учетом пространств имен, структурный поиск и замена, упрощенная установка CodeSniffer/MessDetector, и другие улучшения.
- Symfoniacs Moscow #15 — 2 августа, Москва, традиционная встреча PHP/Symfony разработчиков. На этот раз в гостях у компании Lamoda.
PHP Internals
- [RFC] Namespace Visiblity for Class, Interface and Trait — Предлагается ввести модификаторы доступа для классов, интерфейсов и трейтов для ограничения использования по пространству имен:
Скрытый текстnamespace Example { public class A { private $property; } protected class B { public $property; } private class C { protected $property; } } namespace OtherVendor { public class Factory { public function A() { return new \Example\A(); // Allowed by public } public function B() { return new \Example\B(); // Not allowed because // namespace is not shared } public function C() { return new \Example\C(); // Not allowed because // not from same namespace } } }
Инструменты
- PHLAK/Twine — Объектная обертка для работы со строками. Альтернатива danielstjules/Stringy.
- atlasphp/Atlas.Orm 3.0 — Интересная ORM.
- makasim/values — Библиотека пытается объединить лучшее из мира объектов и массивов. Работаете с объектами как обычно, а под капотом будут использоваться массивы.
- AI-BOLIT — Бесплатный антивирусный сканер для PHP-сайтов.
- spatie/crawler — Мощный краулер на базе Guzzle, а также Chrome и Puppeteer для рендеринга JavaScript-сайтов.
- spatie/code-outliner — Пакет создаст визуальное представление вашего кода, чтобы понять как он воспринимается, абстрагировавшись от содержания.
Материалы для обучения
Symfony
- Неделя Symfony #603 (16-22 июля 2018)
- Неделя Symfony #602 (9-15 июля 2018)
Опыт Rambler Group: Управление React компонентами из Symfony
Yii
Laravel
- chelout/laravel-relationship-events — Библиотека с событиями для связанных сущностей Eloquent.
- rennokki/befriended — Соц-медиа возможности для Eloquent: подписчики, блокирование, фильтры.
- beyondcode/laravel-view-xray — Удобно подсветит и подпишет вьюшки на странице.
- beyondcode/laravel-query-detector — Небольшой хелпер, который поможет избежать запросов к БД в цикле.
- beyondcode/laravel-dump-server — Интеграция Symfony Dump Server для Laravel.
- spatie/laravel-event-projector — Стабильный релиз пакета для реализации Event Sourcing в Laravel. Видеобзор и пост в поддержку.
Zend
- zendframework/zend-expressive-swoole — Библиотека предоставляет поддержку асинхронного движка Swoole в Zend Expressive.
- Неделя Zend Framework 2018-07-19
Async PHP
- ReactPHP 1.0.0 LTS — В 2012 году вышел первый релиз ReactPHP v0.1.0. Спустя ровно 6 лет, команда разработчиков анонсировала первый стабильный релиз с долгосрочной поддержкой ключевых компонентов.
- leproxy/leproxy v0.2.2 — HTTP/SOCKS прокси-сервер на ReactPHP.
- clue/reactphp-buzz — Простой асинхронный PSR-7-совместимый HTTP-клиент.
ReactPHP Tutorial #9: POST Requests
CMS
- Serverless PHP — Сравнение вариантов запуска PHP на AWS Lambda: из Nodejs, из Go, с помощью Peachpie на .NET.
- Архитектура децентрализованной соц-сети movim
- Объекты нужно конструировать за один шаг
- PSR-18: The HTTP client PSR — Об истории, проблемах, и будущем стандарта.
- Советы по работе с фикстурами
Чек-лист по безопасности для веб-разработчика- ABI Model Pattern v0.5.6 Beta
- Расширение PHP и Kotlin Native. Часть вторая, осознанная
- Устаревший код – сторонний код
Аудио и видеоматериалы
- Открытый урок по PHP «Основные понятия баз данных»
- Пятничный PHP: бесплатные вебинары от Skillbox
- Dutch PHP Conference 2018 — Видеозаписи всех докладов.
Занимательное
- Риалтайм тайпхинты в PhpStorm – что думаете?
- Rayne/ecoji-php — Base64 — это скучно, закодируй строку в последовательность emoji:
use Rayne\Ecoji\Ecoji; $ecoji = new Ecoji; $ecoji->encode("Base64 is so 1999, isn\'t there something better?\n");
Спасибо за внимание!
Если вы заметили ошибку или неточность — сообщите, пожалуйста, в личку.
Вопросы и предложения пишите на почту или в твиттер.
Прислать ссылку
Поиск ссылок по всем дайджестам
< Предыдущий выпуск: PHP-Дайджест № 134
Комментарии (26)
arturpanteleev
23.07.2018 11:43[RFC] Namespace Visiblity for Class, Interface and Trait — Предлагается ввести модификаторы доступа для классов, интерфейсов и трейтов для ограничения использование по пространству имен:
Вот это нужная тема +++bm13kk
23.07.2018 12:54Можно пример?
arturpanteleev
23.07.2018 15:43Мне видится очень удобной возможность оставить публичными лишь пару классов из разрабатываемого модуля/компонента/контекста и т.д, сделав их своего рода «портами» по которому, остальные части системы будут взаимодействовать с данным модулем. Будет, свеого рода, четкто контроллируемое разработчиком API ну и прочие плюсы от инкапсуляции
springimport
23.07.2018 16:34Ну а если возникнет необходимость расширить библиотеку переписав некоторые части — велкам ту форк? Сейчас же можно написать свое решение «поверх» этой библиотеки не мучаясь с поддержкой форков и т.д.
Как бы да, идея хорошая, но не без недостатков.Fesor
23.07.2018 17:07велкам ту форк?
именно так. Иначе никакой гарантии что ваше "расширение" не сломается в следующем релизе.
И если под "расширением" вы подразумеваете extends — специально для все все классы с интерфейсами сделать final
springimport
23.07.2018 17:13Гарантией выступает фиксация версий или даже версии. Да, это не хорошая практика, но для частного решения вполне подходит. Вот пример: rulerz, основывается на «hoa/ruler»: "~2.0". И вполне работает.
И да, если версия стала камнем преткновения, то можно переопределить ее через repositories и package.Fesor
25.07.2018 11:13для того что бы автор библиотеки мог следовать semver, ему нужно понимать какие изменения ломают обратную совместимость а какие нет. То есть у разработчика должно быть понятие "публичный интерфейс".
Если возможность "отнаследоваться и переопределись" не была заложена как часть этого публичного интерфейса, тем более если классы или методы были отмечены тегом
@internal, разработчик не должен воспринимать это дело как публичный интерфейс и его право ломать обратную совместимость в этом месте в пределах минорного релиза.
Ну и опять же относительно фиксации версий — вы можете зафиксировать конкретную версию. И что, уже обновляться никогда не будете? Если вы пользуетесь исключительно публичным API высока вероятность что обратная совместимость будет поддерживаться довольно продолжительный период.
Вот пример: rulerz, основывается на «hoa/ruler»: "~2.0". И вполне работает.
Как это относится к теме дискуссии? вопервых hoa/ruler в целом предоставяет точки расширения, и это является публичным интерфейсом этой библиотеки. Это в нее заложено было, а потому за обратной совместимостью там следят. Потому опять же не понимаю причем тут оно.
если версия стала камнем преткновения
не версия, а необходимость поддержания обратной совместимости. Мне как автору библиотеки выгодно по максимуму уменьшить варианты использования библиотеки, так как иначе я не могу предсказать кому я чего могу сломать. И даже тот факт что я выкладываю библиотеку с лицензией вида "если я вам чего сломаю — сами виноваты" — это не отменяет того факта что ломать кому-то чего-то просто так это не очень хорошая идея.
springimport
25.07.2018 16:42Да, hoa/ruler скорее о просто расширении.
Если можно использовать продуманный способ расширения — используем.
Если нет, то:
- форк;
- модификация на основе x;
И если с форком все понятно, то модификация скорее всего будет основывается на конкретной фиксированной мажорной версии. Хорошо это или плохо уже другой вопрос, форк тоже поддерживать придется.
В случае модификации первоначальная библиотека теряет независимость и становится лишь частью новой. А с приватными классами это невозможно. Это как если бы при работе с форком вы бы увидев private метод говорили: «Этот метод нельзя редактировать, приватный же.»
Да, для идеального результата лучше форк, наверное. Но так и ddd можно везде применять, только смысла от этого не прибавится.Fesor
25.07.2018 18:04+1А с приватными классами это невозможно.
и это не мои проблемы если вы вдруг решили делать что-то что я не подразумевал когда делал библиотечку.
«Этот метод нельзя редактировать, приватный же.»
Если я форкнул библиотеку то скорее всего не для того что бы добавить в нее фичи которые мне нужны а что бы баг пофиксить. Иначе я не очень понимаю зачем использовать библиотеку которая не очень то мне подходит и при этом ее нельзя расширить.
Но так и ddd можно везде применять, только смысла от этого не прибавится.
Некорректное сравнение.
arturpanteleev
23.07.2018 18:37Расширеямость библиотеки должна быть заложена программистом, разрабатывающим её — например выделением интерфейсов, реализация которых может быть заменена в клиентском коде(в каких нибудь конфигах) или возможностью передать callable, да не важно как по сути.
Также из вашего комментария хорошо виден еще 1 плюс: «переписав некоторые части» — если обсуждаемый rfc одобрят, то разработчик четко сможет контроллировать все точки расширения и свести к минимуму некорректные(по его мнению) варианты использования своей либы, инкапсулировав внутренню логику, что не позволит юзерам переписать что-то не то.
Ну а если вам нужно, как то переписать что-то, что разраб пометил как деталь внутренней реализации, то это 100% уже форк, так как ваше видение либы будет отличаться от видения автора, и по сути это уже самостоятельный проект, хоть и базирующийся на основе другого.springimport
23.07.2018 18:54Наверное, есть несколько идеальных библиотек где все заложено и продумано, но остальные часто не позволяют этого.
Могу привести пример magento 2 с ее системой плагинов: методы protected & private не поддаются переопределению или дополнению через плагины (private classes in RFC) потому что так задумано. Но разработчики не могут предусмотреть все случаи использования и иногда private для метода — ошибка, и тогда приходится переопределять весь метод или даже класс (это fork) который может сломаться при последующих обновлениях.
Вообще, идеальные компоненты с отдельными интерфейсами и реализацией — это будущее. Но правильно ли блокировать изменение реализации и применять soLid в этом случае — вопрос.VolCh
24.07.2018 00:10+1Собственно для того часто и делают классы, методы и свойства приватными, чтобы минимизировать контракты обратной совместимости. Даже просто нервы сохраняет исключением жалоб на переопределение или нецелевое использование сущностей, помеченных как интернал, но технически публичных.
Fesor
25.07.2018 11:14методы protected & private не поддаются переопределению
желание расширять функционал через наследование — плохое желание. В 90% случаев есть варианты лучше.
springimport
25.07.2018 16:56Мне кажется что у вас частные проекты в котором разработчик — сам себе хозяин. Вы, наверное, привыкли что код всегда можно переписать как хочется или тупо не принять код другого. Удобно планировать для себя расширения, это да.
В системах где код — только встраиваемые модули, например, так не всегда получается.Fesor
25.07.2018 18:06Может просто не надо сферических коней обсуждать? приводите конкретные примеры (и если можно не магенту), которые можно обсудить. Иначе это разговор ниочем.
p.s. да, моя ситуация такова что я выбираю решения и проекты, и я целенаправлено не выбираю проекты с магенту и прочими вордпрессами ибо считаю это неверной стратегией развития и реюза кода. Однако не стоит думать что мне не приходится оставлять себе "точки расширения" или что я всегда могу их подобрать так что бы оно было на все случаи жизни. Всего наперед не узнаешь. Но вот либы форкать что бы фичи добавлять мне не приходилось (разве что как PR к этим либам).
springimport
25.07.2018 18:41Короче, не знаю что вам сказать. Сойдемся на том что
магенту и прочими вордпрессами считаю это неверной стратегией развития и реюза кода
в идеальном мире.
VolCh
23.07.2018 23:58Агрегаты и сервисы из DDD. И вообще сокрытие от потребителей деталей реализаций сложных модулей.
evgwed
Я бы отключил эту функцию. Мне не нравится текст в редакторе, который на самом деле отсутствует. Не нравится поведение курсора при клике на такие «фантомы».
Достаточно подсказки типа при Ctrl+Hover.
Fesor
отключите, вам никто не мешает)
хотя соглашусь что фича сомнительная, так как если в коде реально от этого есть польза то есть вопрос к такому коду. Разве что вижу плюс в ситуациях, когда надо разобраться с типами в чем-то сложном, и хочется смотреть всю картину в целом а не только отдельные переменные. Но я бы предпочел это как отдельный режим отображения, который не включен по умолчанию.
shushu
В дебаг режиме всё отлично видно. И это, как по мне — хорошо.
А в редакторе, лично для себя, я нашел это не удобным, и отключил тайпхинтинг функцию в аргументах функций/методов
rdifb0
Нужно было для скриншота еще включить риалтайм тайпхинты для параметров. Месиво было бы знатное.
glagola
А такой же бред уже был для аргументов функций, они туда выводили имена аргументов. пользоваться было просто невозможно, код разбухал настолько что даже вылазил за пределы экрана — вырубил сразу, и тут думаю тоже самое будет. А вообще считаю среда мега перегружена функционалом, я использую наверно процетов 20%… разбираться просто нет времени… уж лучше бы собрали статистику по использованию функций и сделали отдельный редактор с наиболее часто используемыми функциями, а остальные просто выкинули…
Fesor
20% это уже не мало, либо вы преувеличили. Что до "остальное выкинуть" — не выйдет. У всех это разные 20%. Да и опять же, вы уверены что вы не пользуетесь какими-то фичами потому что они вам не нужны, или вы просто о них не знаете?)
glagola
не могу сказать что я знаю весь список фич и из них я использую 20%, скорее из тех что я знаю, я использую 20%
Без статистики нельзя делать такие выводы. По опыту в других областях, могу сказать, что люди далеко не уникальны в своем поведении. Безусловно, будут те кто пострадают, т.к. придется поставить процентный порог начиная, с которого фича будет считаться популярной.
VolCh
Как собрать статистику по «пассивным» (типа отображения) фичам, которые включены по умолчанию, но одним они нравятся, а другие не знают или не могут отключить?