Комментарии 37
mysqli используют только ...

чуть менее 40% веб-сайтов всего мира ;-)

Это да :-) Кстати, пересекается с заметкой про обновление на PHP 8.0. Там как раз автор ссылается на то, что значительная часть пользователей PHP не разработчики (WordPress).

Да, и недавно в комменте к моей статье показали еще одну проблему 8ки — 3v4l.org/rmN8l
К сожалению, ни один статический анализатор эти проблемы не показывает.
pronskiy, а есть ли планы добавить проверки потенциальных проблем с 8кой в PHPStorm?
Да, и недавно в комменте к моей статье показали еще одну проблему 8ки — 3v4l.org/rmN8l

Это как раз вполне ожидаемое и документированное поведение https://wiki.php.net/rfc/string_to_number_comparison


Есть на странице релиза https://www.php.net/releases/8.0/en.php#saner-string-to-number-comparisons и упоминалось в дайджестах 151, 185. Но согласен, что выглядит как то, что хотелось бы найти автоматически.


pronskiy, а есть ли планы добавить проверки потенциальных проблем с 8кой в PHPStorm?

Обсудим в команде, спасибо за наводку.

Конечно, это документированное поведение.
Проблема вот в чем: если в функции/методе тип возврата — строка, любое сравнение результата вызова метода с 0, или при возврате int сравнение с '', или сравнение двух вызовов друг с другом в if, for, while, etc — это потенциальная ошибка, о которой узнать невозможно.
К примеру, метод может возвращать результат запроса вида 'SELECT col FROM… LIMIT 1',

Попробуйте задетектить это с помощью phpgrep. Должно получиться просто и быстро. Заодно можете сделать PR в общий список инспекций для этой утилиты.

Да, phpgrep или в PhpStorm можно сделать поиск/замену/катомнуюинспекцию с помощью Structural Search and Replace.



Только два шаблона поиска придется сделать: $string$ == $int$ и $int$ == $string$.

Никита предлагает сделать возможным использование объектов в качестве ключей обычных массивов.
— кто то знает зачем это?
Поводом для предложения послужил тот факт, что в RFC Enumerations предлагается сделать значения енамов объектами. И соответственно тогда их нельзя будет использовать в качестве ключей массивов. А это существенный минус.
Но это не отвечает на вопрос зачем это. Чем дальше тем больше бесполезных изменений в языке делают
Это возможность, которая не привносит минусов. Не нравится — не используйте

Чтобы хранить отбражение одних объектов на другие. Во всех нормальных языках нет ограничения на тип ключа в подобных коллекциях. Но да, для php это не нужно. :)

Языки, в которых есть нормальные коллекции, а не странные массивы. Желательно со статической типизацией.

Так я не настаиваю. :) Удивляйтесь дальше "предложениям Никиты". И не забывайте на ночь зубрить таблицы сравнения и приведения типов.

Какие-то карты составлять типа:


$found = [
 $product1 => true,
 $product2 => false,
];

а не


$found = [
 $product1->id => true,
 $product2->id => false,
];

а потом выгребать по id

PHP Russia переносится на 28 июня 2021 года.
Япония хотят отменить Олимпиаду, а организаторы «PHP Russia» все ищут дно короновируса D)

Опять для них не очевидны очевидные вещи!
организаторы «PHP Russia» в комменте выше тегнули Yii Auth и поправили статью ;-)
Предположение, т.к. нигде про него не пишут. Непонятно на какой стадии обсуждения по нему.

Файберы ведь уже пытались протащить в ПХП года три назад и смутные ощущения что история повторяется )

Есть другая информация?
Спасибо! «хорошие шансы, что добавят» — вот этой фразы нигде в явном виде не было, поэтому было недопонимание происходящего.

Роман, а вы смотрели в код вот этого вот?


walkor/Workerman — Асинхронный движок с простым API, поддержкой HTTP, WebSocket, SSL. Может работать в связке с libevent.

Тестов нет, мин.версия PHP 5.3, посмотрел по диагонали код — глаза не вытекли, конечно, но слезы проступили…
что это и зачем это в дайджесте?!

А вы текст дайджеста читали? Во втором параграфе описания указано зачем это в дайджесте.

А, ну то есть, если самый быстрый по бенчмаркам, то уже и не важно, что он без тестов, и з сомнительным качеством кода?! Окай, буду знать:))

Так ему уже скоро 10 лет как. Примерно как тому самому "пхпдемону". Такое же "протестированное временем" решение, как и какая-нибудь phpmyadmin.

Про temporal кто-то может подсказать, что можно почитать детальнее case study про миграцию в рамках своего легаси-приложения: был, значит, сайт на php с многообразным функционалом и вдруг мы поняли что можем все переписать(?) на temporal или встроить его в процесс?

Рекомендую зайти в официальное комьюнити temporal: https://community.temporal.io/


На практике все переписать не получится, но изолировать часть процессов — без проблем. Для начала нужно выделить части бизнес логики в виде activity: https://docs.temporal.io/docs/activities (в них можно записать большую часть легаси кода)


А после смотреть на реализацию workflow сверху: https://docs.temporal.io/docs/workflows

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.