现已上线！2025 年 Telegram 研究 — 年度关键洞察 
Пых
前往频道在 Telegram
Блог Валентина Удальцова о разработке на PHP. Хобот @phpyhobot https://youtube.com/@phpyh https://vkvideo.ru/@phpyh https://t.me/isPHPdying Статистика: https://t.me/INOTAROBOT?start=st1219340804 Для связи используйте личные сообщения канала.
显示更多8 111
订阅者
+324 小时
无数据7 天
+330 天
数据加载中...
相似频道
标签云
进出提及
---
---
---
---
---
---
吸引订阅者
六月 '26
六月 '26
+34
在0个频道中
五月 '26
+141
在0个频道中
Get PRO
四月 '26
+66
在0个频道中
Get PRO
三月 '26
+72
在1个频道中
Get PRO
二月 '26
+92
在3个频道中
Get PRO
一月 '26
+83
在2个频道中
Get PRO
十二月 '25
+69
在3个频道中
Get PRO
十一月 '25
+89
在0个频道中
Get PRO
十月 '25
+90
在1个频道中
Get PRO
九月 '25
+131
在3个频道中
Get PRO
八月 '25
+162
在4个频道中
Get PRO
七月 '25
+161
在3个频道中
Get PRO
六月 '25
+144
在17个频道中
Get PRO
五月 '25
+143
在2个频道中
Get PRO
四月 '25
+138
在3个频道中
Get PRO
三月 '25
+125
在3个频道中
Get PRO
二月 '25
+238
在5个频道中
Get PRO
一月 '25
+177
在6个频道中
Get PRO
十二月 '24
+235
在1个频道中
Get PRO
十一月 '24
+383
在5个频道中
Get PRO
十月 '24
+269
在4个频道中
Get PRO
九月 '24
+103
在1个频道中
Get PRO
八月 '24
+132
在2个频道中
Get PRO
七月 '24
+89
在0个频道中
Get PRO
六月 '24
+106
在4个频道中
Get PRO
五月 '24
+177
在2个频道中
Get PRO
四月 '24
+266
在0个频道中
Get PRO
三月 '24
+365
在1个频道中
Get PRO
二月 '24
+658
在0个频道中
Get PRO
一月 '24
+352
在5个频道中
Get PRO
十二月 '23
+274
在3个频道中
Get PRO
十一月 '23
+140
在3个频道中
Get PRO
十月 '23
+121
在1个频道中
Get PRO
九月 '23
+191
在0个频道中
Get PRO
八月 '23
+354
在0个频道中
Get PRO
七月 '23
+328
在0个频道中
Get PRO
六月 '23
+354
在0个频道中
Get PRO
五月 '23
+493
在0个频道中
Get PRO
四月 '23
+290
在0个频道中
Get PRO
三月 '23
+689
在0个频道中
Get PRO
二月 '23
+353
在0个频道中
Get PRO
一月 '23
+250
在0个频道中
Get PRO
十二月 '22
+217
在0个频道中
Get PRO
十一月 '22
+146
在0个频道中
Get PRO
十月 '22
+113
在0个频道中
Get PRO
九月 '22
+74
在0个频道中
Get PRO
八月 '22
+166
在0个频道中
Get PRO
七月 '22
+143
在0个频道中
Get PRO
六月 '22
+142
在0个频道中
Get PRO
五月 '22
+67
在0个频道中
Get PRO
四月 '22
+54
在0个频道中
Get PRO
三月 '22
+57
在0个频道中
Get PRO
二月 '22
+141
在0个频道中
Get PRO
一月 '22
+157
在0个频道中
Get PRO
十二月 '21
+181
在0个频道中
Get PRO
十一月 '21
+92
在0个频道中
Get PRO
十月 '21
+64
在0个频道中
Get PRO
九月 '21
+47
在0个频道中
Get PRO
八月 '21
+63
在0个频道中
Get PRO
七月 '21
+75
在0个频道中
Get PRO
六月 '21
+127
在0个频道中
Get PRO
五月 '21
+62
在0个频道中
Get PRO
四月 '21
+113
在0个频道中
Get PRO
三月 '21
+238
在0个频道中
Get PRO
二月 '21
+316
在0个频道中
Get PRO
一月 '21
+242
在0个频道中
Get PRO
十二月 '20
+3 333
在0个频道中
| 日期 | 订阅者增长 | 提及 | 频道 | |
| 06 六月 | +3 | |||
| 05 六月 | +4 | |||
| 04 六月 | +7 | |||
| 03 六月 | +3 | |||
| 02 六月 | +7 | |||
| 01 六月 | +10 |
频道帖子
| 2 | Whole Value a.k.a. Value Object
Я сейчас работаю над кодом, которому для работы требуется список параметров функции:
/**
* @param list<ReflectionParameter> $parameters
*/
function make(array $parameters): Something {}
На первый взгляд, всё здорово. list<ReflectionParameter> выражает минимально необходимое знание для решения задачи да и вообще это список из объектов-значений, а не каких-то там примитивов.
Но есть нюанс.
В такой make можно передать невозможный список параметров, например:
$trimReflection = new ReflectionFunction(trim(...));
make(array_reverse($trimReflection->getParameters()));
С точки зрения типов всё верно, но инвариант "опциональные параметры идут после обязательных" в переданном списке нарушен, что может привести к неправильной работе функции. Можно передать параметры от разных функций (тогда $parameters[$i]->getDeclaringFunction() будет давать неконсистентный результат), можно поставить вариадик в начало — способов задать неверный список много, потому что list<ReflectionParameter> ничего толком не регламентирует.
Если функция работает с концепцией "список параметров валидной сигнатуры", она должна принимать ReflectionFunctionAbstract и сама вызывать getParameters():
function make(ReflectionFunctionAbstract $function): Something
{
$parameters = $function->getParameters();
// ...
}
Теперь в теле make можно быть уверенным, что список параметров удовлетворяет всем инвариантам, ведь отрефлексировать функцию с неверной сигнатурой не получится...
Хотя подождите... Можно же так поломать:
final class MessedReflectionFunction extends ReflectionFunction
{
public function getParameters(): array
{
return array_reverse(parent::getParameters());
}
}
make(new MessedReflectionFunction(trim(...)));
Но это уже разговор про LSP и что наследники не должны нарушать инварианты родителей — тема для другого поста. 😊
Мораль такая: принимайте не просто минимум знаний, а минимум, гарантирующий необходимые инварианты. Это и есть концепция Whole Value.
⸻
Этот пост я разместил неделю назад в 🐘 PHPeople. | 2 780 |
| 3 | 没有文字... | 5 033 |
| 4 | Горю с PHPStan
Все привыкли ограничивать дженерики типов сверху (upper bound): @template T of U. Но бывают ситуации, когда дженерик логично ограничить снизу (lower bound), в частности другим дженериком.
Пример. Представьте, что существует ссылка на какое-то значение и нужно заапкастить (преобразовать в супертип) тип значения в этой ссылке:
use Psr\Log\LoggerInterface as Logger;
use Monolog\Logger as Monolog;
use Typhoon\Type;
/**
* @template T
*/
interface Ref
{
/**
* @template S, где S — супертип для T
* @param Type<S> $super
* @return self<S>
*/
public function as(Type $super): self;
}
/**
* @param Ref<Monolog> $ref
* @return Ref<Logger>
*/
function upcastLogger(Ref $ref): Ref
{
return $ref->as(Type\objectT(Logger::class));
}
В Java wildcards это выражается так: ? super T. В Scala оператором: [S >: T].
В PHPStan, о чудо, тоже начали об этом думать аж в 2021 году: phpstan/phpstan/issues/5179.
Я был в курсе, и, не глядя в issue, решил попробовать. Пишу:
/**
* @template S super T
* @param Type<S> $super
* @return self<S>
*/
public function as(Type $super): self;
Анализатор говорит No issues!, я радостно продолжаю работать. А потом намеренно пробую вызвать $ref->as(Type\stringT) и всё равно вижу No issues!
Разбираюсь и понимаю, что PHPStan поддержал пару лет назад синтаксис super, но только в PHPDoc-парсере! Исходный тикет в анализаторе всё ещё не закрыт!
Представьте, что в PHP добавили property hooks только на уровне синтаксиса — по факту они вообще не работают. Как вам такая фича?
Между PHP-анализатором и PHPDoc-парсером есть фундаментальный каплинг (то есть, кохижен). Нельзя поправить одно и не учесть это в другом. Нормально разделять компоненты и делать один более универсальным, но тогда должны быть фича-флаги, при помощи которых второй компонент выключает (opt-out) или не включает (opt-in) неподдерживаемое поведение в первом.
⸻
Этот пост я разместил неделю назад в 🐘 PHPeople. | 6 392 |
| 5 | base64url
Хотел предложить base64url_encode(), base64url_decode() в Core — давно стандартизованная кодировка, используется в JWT, OAuth 2.0 и WebAuthn.
Но потом нашёл в почте прошлогодний тред с куда более фундаментальным RFC:
namespace Encoding;
enum Base64
{
case Standard;
case UrlSafe;
case Imap;
}
enum PaddingMode
{
case VariantControlled;
case StripPadding;
case PreservePadding;
}
enum DecodingMode
{
case Forgiving;
case Strict;
}
enum TimingMode
{
case Variable;
case Constant;
}
/**
* @throws UnableToEncodeException
*/
function base64_encode(
string $data,
Base64 $variant = Base64::Standard,
PaddingMode $paddingMode = PaddingMode::VariantControlled,
TimingMode $timingMode = TimingMode::Variable,
): string;
/**
* @throws UnableToDecodeException
*/
function base64_decode(
string $data,
Base64 $variant = Base64::Standard,
DecodingMode $decodingMode = DecodingMode::Strict,
TimingMode $timingMode = TimingMode::Variable,
): string;
Ну и аналогичные функции для base16, base32, base58 (Bitcoin) и base85 (PDF).
https://wiki.php.net/rfc/data_encoding_api
Спросил автора, не планирует ли он возобновить работу над RFC. Вот его ответ:
Hi Valentin,
We are still working on it with Tim Düsterhus doing the full implementation.
Best regards
Так что ждём!
⸻
Этот пост я разместил неделю назад в 🐘 PHPeople. | 6 308 |
| 6 | Используешь Dev Containers для локальной разработки? | 0 |
| 7 |  视频消息 | 0 |
| 8 | Хроники пакета exceptionally
Вы наверняка знаете проект thecodingmachine/safe.
A set of core PHP functions rewritten to throw exceptions instead of returning false when an error is encountered.
// вместо
$contents = @file_get_contents($file);
if ($contents === false) {
throw new RuntimeException("File {$file} is not readable");
}
// пишем
$contents = Safe\file_get_contents($file);
Такой подход мне всегда казался максимально бредовым: скодогенерировать обёртки над всеми стандартными PHP-функциями и написать плагины под каждый статанализатор вместо того, чтобы воспользоваться композицией функций.
Поэтому ночью 3 августа 2019 года я написал библиотечку vudaltsov/exceptionally, которая решала проблему куда более элегантно:
$contents = exceptionallyCall('file_get_contents', $file);
Тогда ещё не было стрелочных функций и first class callable синтаксиса, поэтому краткая запись могла выглядеть только так.
Забавно, что утром в тот же день в паре кварталов от моей квартиры загорелся склад, подробнее в личном канале.
Через 2 дня я предложил RFC в Symfony, а ещё через неделю Yonel Ceruto добавил статический метод ErrorHandler::call(), он там есть и по сей день.
Но настали времена, когда я больше не пишу на Symfony, а функция всё ещё актуальна. Поэтому я решил перенести vudaltsov/exceptionally в thesis/exceptionally, упростить и приправить дженериками:
/**
* @template T
* @param callable(): (T|false) $function
* @return T
* @throws \ErrorException
*/
function exceptionally(
callable $function,
int $errorLevels = E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED,
): mixed {}
// PHP < 8.6
$contents = exceptionally(static fn () => file_get_contents($file));
// PHP >= 8.6 с partial function application
$contents = exceptionally(file_get_contents($file, ...));
Исключение ErrorException, кстати, существует в ядре ровно для этой задачи, поэтому помимо стандартных параметров оно принимает файл и номер строки.
Пользуйтесь Thesis Exceptionally на здоровье!
composer require thesis/exceptionally
⸻
Этот пост я разместил неделю назад в 🐘 PHPeople. Кстати, общая группа там теперь бесплатная — подписывайся! | 0 |
| 9 |  Прошло ровно полгода с Пых.конф’25 — что это значит?
Это значит, что записи докладов теперь доступны каждому!
Смотреть 28 крутых докладов на 📹 YouTube, 📹 VK Видео. | 0 |
