Вышел PhpStorm 2021.3

2.Тоже жду эту фичу. Проголосовать можно тут: https://youtrack.jetbrains.com/issue/IDEA-228145

«Союзмультфильм» назвал критиков перезапуска «Ну, погоди!» взрослой аудиторией, на которую не рассчитан новый мультфильм

Лео и Тиг, кстати, неплох, да еще и с пасхалками

PHP Generics. Right here. Right now

PHP выполняет проверки типов в runtime.Значит, все аргументы дженериков должны быть доступны через reflection в runtime.А этого не может быть, потому что информация о аргументах дженериков после генерации конкретных классов стирается.

Как вариант - добавить в сгенерированые классы атрибуты, в которых уже эти данные предоставить

PHP 8.1: до и после

Я бы посмотрел на тесты этого класса

PHP Дайджест № 206 (15 – 29 июня 2021)

Увы, да. В RFC как раз есть пример:

$qb->select('u')
   ->from('User', 'u')
   ->where('u.id = ' . $_GET['id']); // INSECURE

PHP Дайджест № 206 (15 – 29 июня 2021)

Это как раз сделано для того, чтобы в query builder нельзя было передать пользовательский ввод. Только через placeholder-ы

Чистим пхпшный код с помощью DTO

Уже есть: https://symfony.com/blog/new-in-symfony-5-3-inlined-serialization-context

Чистим пхпшный код с помощью DTO

1. В 5.3.0 эта проблема исправлена

   
   

2. Можно сохранять результаты парсинга в аттрибуты реквеста, а в декораторе к ArgumentResolverInterface удалять этот ключ

   
   

   if ($request->attributes->has('_parsed_json')) {
   $json = $request->attributes->get('_parsed_json');
   } else {
   $json = json_decode($request->getContent(), true);
   $request->attributes->set('_parsed_json', $json);
   }

   
   

Чистим пхпшный код с помощью DTO

Можно сделать через соглашение. Сначала искать по имени аргумента

$json = \json_decode($request->getContent(), true);
if (array_key_exists($argument->getName(), $json)) {
    $dto = $this->denormalizer->denormalize($json[$argument->getName()], $argument->getType(), 'json');
} else {
    $dto = $this->serializer->deserialize($json, $argument->getType(), 'json');
}

Можно воспользоваться благами php8

public function userAction(
    #[FromKey('user')] User $user,
    #[FromKey('fruit')] Fruit $fruit
)

$attribute = $argument->getAttribute();
if ($attribute instanceof FromKey) {
    $json = \json_decode($request->getContent(), true);
    $model = $this->denormalizer->denormalize($json[$attribute->key], $type, 'json');
} else {
    $model = $this->serializer->deserialize($request->getContent(), $type, 'json');
}

Чистим пхпшный код с помощью DTO

Чем не устроил symfony/serializer?

Prototype Design Pattern в Golang

Увидел. Спорно, все-таки сама статья не об этом. И мне кажется, не хватает хаба "Я пиарюсь", т.к. по ссылке просят 8к рублей за реализацию шаблонов на PHP

Prototype Design Pattern в Golang

А при чем тут php?

Еще немного про сервисный слой в PHP

Почему сразу не передавать MailEventInterface?

NotificationService::notify(MailEventInterface $event): void;

Заодно можно будет избавится от массива, а сразу передавать нужные параметры в эвент. В противном случае каждый раз надо будет заходить в реализацию makeNotificationEvent, смотреть какой эвент должен создаться при order_created и какой массив параметров он ожидает

public function createOrder(CreateOrderRequest $request)
{
    $this->notificationService->notify(new OrderCreatedEvent($order)); 
}

Еще немного про сервисный слой в PHP

Можно ли использовать сервисы внутри сервисов?
Я бы однозначно не рекомендовал такую практику, так как этим вы нарушаете single responsibility принцип, делая ваш код, к тому же, достаточно запутанным.

Тут нет ошибки? Потому что во втором пункте вы по сути предлагаете использовать сервисы (OrderService и NotificationService) внутри сервиса (CreateOrderOperation)

Разделение кода и текста: прототип

Получается, если разработчик решил порефакторить код, а работа с переводами уже закончена, т.е. никто в админку не зайдет и не увидит этих сообщений, то могут быть проблемы?

Разделение кода и текста: прототип

Часто возникает дилемма — использовать существующий текст или создать новый? А вдруг в этом новом месте чуть-чуть другой контекст?

А вот эта проблема как решается? К примеру у нас есть одна и та же фраза, но в разных файлах и, соответственно, разный контекст. Правильно я понимаю, в админке будет зарегистрированы две фразы и соответственно то, где они вызываются, и переводчикам самим предлагается определить контекст перевода?
А если вдруг мы код отрефакторили и теперь эти фразы вызываются из другого места?

Разделение кода и текста: прототип

Как планируется вычленять переменные из строк?

We are glad to have you back {$name}

9 самых популярных PHP-фреймворков

И все-таки какие критерии?

composer create-project mezzio/mezzio-skeleton mezzio
composer create-project symfony/skeleton symfony

Размер:

15M ./mezzio
9,1M    ./symfony

Количество файлов в скелете?

cd ./mezzio
git status | grep 'new file' | wc -l
      31
cd ./symfony
git status | grep 'new file' | wc -l
      19

9 самых популярных PHP-фреймворков

О чем и говорит TheCluster. Этого уже нет. Вот, к примеру, конфиг для демо приложения. Он отличается от дефолтного всего несколькими строчками.
Ну а что касается аннотаций, то их можно не использовать: php, yaml, xml — выбирай не хочу

Environment Synchronization

Эти переменные используются в описании сервисов и конфигов, т.е. напрямую в коде обращения к ним нет. Загрузка идет через Dotenv компонент. Если вдруг понадобится, то можно обратится к ним стандартным способом, но это не рекомендуется и может привести к ошибкам компиляции контейнера.

Если речь про дефолтные значения, то их можно задать в конфиге:

parameters:
    env(FOO): bar

но не думаю, что так кто-то делает, если они все равно загружаются из .env. Иначе это добавляет еще одно место, где нужно синхронизировать дефолтные значения.

Правильно понимаю, что вам нужно синхронизировать дефолтные значения не только в .env.example, но и везде, где эти переменные используются (к примеру, везде где есть вызов env('FOO', 'bar'))?