Вместе с PHP-разработчиками Александром Макаровым (@SamDark), Валентином Удальцовым (@vudaltsov) и наставником Хекслета по PHP Владленом Гилязетдиновым (@funkylen) разбираемся, какие новые фичи появились в PHP 8.2, насколько эти изменения глобальны и какую роль в них сыграл проект РHP Foundation.
Эта статья — саммари стрима YouTube-канала PHP Point.
Кстати, ежегодный опрос русскоязычного PHP-сообщества с итогами года запущен! Результатами поделимся в конце января.
Главные изменения в PHP 8.2
Readonly-классы
Поля readonly сделали еще до версии 8.2. Раньше писать в них код и читать его можно было только в конструкторе. А теперь для этого не нужно помечать каждое поле — достаточно отметить весь класс как readonly.
Как выглядел код в предыдущих версиях PHP:
class BlogData
{
public readonly string $title;
public readonly Status $status;
public function __construct(string $title, Status $status)
{
$this->title = $title;
$this->status = $status;
}
}Как выглядит код в PHP 8.2:
readonly class BlogData
{
public string $title;
public Status $status;
public function __construct(string $title, Status $status)
{
$this->title = $title;
$this->status = $status;
}
}Но у фичи есть особенности:
Readonly-классы недоступны для классов с необъявленными типами.Также
readonly-классы недоступны для классов со статическими свойствами.Если мы захотим наследоваться от старого
readonly-класса, новый тоже должен быть Readonly.
Типы в виде дизъюнктивной нормальной формы (ДНФ)
Теперь вместо того, чтобы указывать тип mixed для аргументов в методах, можно просто перечислять необходимые типы через амперсанд.
Как выглядел код в предыдущих версиях PHP:
class Foo {
public function bar(mixed $entity) {
if ((($entity instanceof A) && ($entity instanceof B)) || ($entity === null)) {
return $entity;
}
throw new Exception('Invalid entity');
}
}Как выглядит код в PHP 8.2:
class Foo {
public function bar((A&B)|null $entity) {
return $entity;
}
}Пожелание от меня: будьте осторожны с этой фичей. Она позволяет много методов объединять в один. Если бы я программировал приложения, то так не делал бы. А вот во фреймворках она будет очень кстати, потому что иногда, ради красивой API, мы сознательно жертвуем такой вот правильностью — используем подход с mixed-типами в сигнатуре.
Самостоятельные типы null, false и true
Это изменение единогласно приняла вся команда разработчиков PHP, так как в ядре PHP есть методы, классы и функции, которые возвращают false или true.
Если у вас метод никогда не возвращает false, то теперь можно указать, что он возвращает true или значение. Или наоборот, null и значение, или false и значение. Фича удобная и делает язык немного строже.
Как выглядел код в предыдущих версиях PHP:
class Falsy
{
public function almostFalse(): bool { /* ... */ *}
public function almostTrue(): bool { /* ... */ *}
public function almostNull(): string|null { /* ... */ *}
}Как выглядит код в PHP 8.2:
class Falsy
{
public function alwaysFalse(): false { /* ... */ *}
public function alwaysTrue(): true { /* ... */ *}
public function alwaysNull(): null { /* ... */ *}
}Модуль «Random»
Random — это целый пак разных интерфейсов. Особенности фичи:
Разработчики сделали объектно-ориентированный API.
Каждый инстанс независимый — то есть для разных целей можно инстанцировать n-штук псевдослучайных генераторов, которые никогда не пересекутся. Стало более безопасно.
Mersenne twister заменен на интерфейс Engine. Раньше
mt_rand()надо было инициализировать. Он был нужен не для всяких крипто-фич, а для того чтобы, например, сортировать массивы в случайном порядке.mt_rand()работал достаточно быстро, поэтому использовать его для утилитарных задач было неплохо. Теперь его заменили на интерфейс Engine, который предоставляет готовые реализации.
Как выглядит код в PHP 8.2:
use Random\Engine\Xoshiro256StarStar;
use Random\Randomizer;
$blueprintRng = new Xoshiro256StarStar(
hash('sha256', "Example seed that is converted to a 256 Bit string via SHA-256", true)
);
$fibers = [];
for ($i = 0; $i < 8; $i++) {
$fiberRng = clone $blueprintRng;
// Xoshiro256**'s 'jump()' method moves the blueprint ahead 2**128 steps, as if calling
// 'generate()' 2**128 times, giving the Fiber 2**128 unique values without needing to reseed.
$blueprintRng->jump();Константы в трейтах
Теперь можно объявлять константы внутри трейтов. Особенность фичи — нельзя получить доступ к константе через имя трейта, но можно через класс, который использует этот трейт.
Очень логичное изменение, на мой взгляд. Трейт сам по себе — это копипаст. Копипаст — штука опасная, но иногда полезная (у нас есть принцип «don't repeat yourself»). И трейт — это один самых неинвазивных способов что-то повторить, который легко потом отрефакторить.
Как выглядит код в PHP 8.2:
trait Foo
{
public const CONSTANT = 1;
}
class Bar
{
use Foo;
}
var_dump(Bar::CONSTANT); // 1
var_dump(Foo::CONSTANT); // ErrorДинамические свойства объявлены устаревшими
В классах PHP можно было динамически присваивать значения свойствам, которые мы не объявили ранее, и эти свойства появлялись после классов.
Теперь так сделать нельзя — будет появляться Deprecation notice. Но если сильно нужно, динамическими свойствами можно пользоваться, если пометить класс аннотацией #[\AllowDynamicProperties]. В экземплярах stdClass динамические свойства по-прежнему можно использовать.
Как выглядел код в предыдущих версиях PHP:
class User
{
public $name;
}
$user = new User();
$user->last_name = 'Doe';
$user = new stdClass();
$user->last_name = 'Doe';Как выглядит код в PHP 8.2:
class User
{
public $name;
}
$user = new User();
$user->last_name = 'Doe'; // Deprecated notice
$user = new stdClass();
$user->last_name = 'Doe'; // Still allowed#[\SensitiveParameter]
Это маленькая, но очень классная фича, которая мельком упоминается в официальном анонсе.
Параметры в методах теперь можно обозначить как #[\SensitiveParameter]. Ниже в коде так отмечен параметр $secret, и в логах вместо значения параметра secret написано (Object(SensitiveParameterValue).
function sensitiveParametersWithAttribute(
#[\SensitiveParameter]
string $secret,
string $normal
) {
throw new Exception('Error!');
}Exception: Error! in example.php:15
Stack trace:
#0 example.php(25): sensitiveParametersWithAttribute(Object(SensitiveParameterValue), 'normal')
#1 {main}Считаю это изменение очень крутым, так как теперь у нас не будут утекать всякие ключи от API, пароли от базы. Команда разработчиков PHP практически единогласно проголосовала за эту фичу.
Какие еще изменения произошли
Расширение enum в константах
Раньше, чтобы использовать enum, надо было дублировать их значение. Это было очень неприятно: enum есть, а в объявлениях констант нельзя было из них что-то использовать. Теперь можно: новая фича уравнивает весь синтаксис. Классно, что язык эволюционирует в сторону удобства и большей консистентности.
const C = [self::B->value => self::B];iterator_() + iterables
Теперь можно передавать в методы iterator_() тип \Traversables. Это просто замечательно, потому что раньше приходилось проверять, является ли аргумент объектом типа \Traversable, и если да, то надо было его конвертить. В PHP 8.2 можно больше не проводить эти проверки, что уменьшает количество кода и делает его более приятным и читаемым.
Расширена рефлексия
Можно узнать, анонимный ли метод —
ReflectionFunction::isAnonymous()Можно узнать, есть ли у метода прототип —
ReflectionMethod::hasPrototype()
Новые функции memory_reset_peak_usage
Функции сбрасывают статистику по пиковому использованию памяти. Это очень полезно для EventLoop на PHP, Roadrunner и Swoole — мы сможем скинуть потребляемую память после запроса и измерить ту, которая ушла конкретно на один запрос.
Что признали устаревшим или убрали
Интерполяция в строках вида
${}Не рекомендуется использовать функции
utf8_encodeиutf8_decodeФункции
strtolowerиstrtoupperтеперь не учитывают локаль — это круто, потому что версии PHP, установленные в двух системах Linux, могут работать по-разному из-за выбранной дефолтной локали.Убрали много форматов
callable:
“self::method”“parent::method”“static::method”[“self”, “method”][“parent”, “method”][“static”, “method”][“Foo”, “Bar::Method”][new Foo, “Bar::Method”]
Мое мнение — на PHP 8.2 определенно стоит переходить хотя бы из-за крутых улучшений синтаксиса. Он все еще делает код более читаемым и понятным. Также разработчики пофиксили разные мелкие баги, которые мы не упомянули, но их было много.
Какие изменения PHP 8.2 еще в разработке
Некоторые разработчики считают, что в новую версию PHP добавили очень мало изменений. На самом деле, в РHP 8.2 было много саппортных вещей: код вычищали, из него что-то убирали. Каждое изменение, которое вводили разработчики, непросто описать в фичах. Да и вряд ли всем будет интересно, какие куски кода рефакторили. Так что по объему работы релиз 8.2 не отличается от предыдущих релизов. Просто в нем чуть меньше фич.
Большие усилия к разработке версии 8.2 приложили ребята из PHP Foundation — проекта, который финансирует разработчиков, готовых контрибьютить в PHP.
PHP Foundation создали много известных компаний, среди которых JetBrains, Automattic, Laravel. Проект запустили 22 ноября 2021 года, и за год коллектив из десяти администраторов-добровольцев и шести разработчиков внесли почти половину коммитов в ядро языка PHP и расширения.
В новую версию языка PHP Foundation имплементировал интерполяцию в строках вида ${}, readonly-классы, самостоятельные типы null, false и true, тип true, типы в виде дизъюнктивной нормальной формы и получение свойств перечислений в константных выражениях.
Документация по PHP 8.2 еще в разработке, и разработчик PHP Foundation Джордж П. Баньярд сейчас отслеживает прогресс в изменениях. Вместе с командой он обсуждает эти нововведения:
Помочь составить документацию может каждый из нас — это, как говорится, good first issue (несложные задачи, выполнить которые под силу новичкам).
Также PHP Foundation планирует выдвинуть на обсуждение новые изменения в будущем релизе PHP 8.3.
Комментарии (52)
grek_cheburek
13.12.2022 20:21+8Вот понять не могу. К php программистам так с презрением относятся, а сам язык мне нравится. Сколько статей читал про то, что он плохой, что лучше его не использовать и на php только веб макаки сидят, но он развивается и сайтов много на нем работает.
asd111
14.12.2022 01:06+3Посмотри исходный код 1с Битрикс или wordpress и потом посмотри количество вакансий на битрикс и wordpress и всё встанет на свои места. А так на мой взгляд современный php уже сложнее чем c#, но при этом в c# на dotnet 7 есть простая асинхронность, простой entity framework и linq для работы с множествами и бд, включая миграции бд, и ещё есть хороший и быстрый фреймворк для web api и всё это дело поддерживает крупная компания. И вот на фоне такой технологии стоит php в котором Битрикс самый популярный фреймворк в РФ, а ларавел занимает последние места в тестах производительности и как то получается что сейчас лучше взять c# с dotnet 7 и получить за то же время более качественный результат.
tzlom
14.12.2022 01:36+9с c# в комплекте идет весь M$ серверный стек с хорошим ценником. да, можно запускать в моно, все в курсе, но кто так делает? да и аргументов что результат будет более качественный вы не привели, так что тут я не уверен что С# будет хорошо выглядеть. да, как язык он ничего так, но языком дело не ограничивается
ColdPhoenix
14.12.2022 09:44+5А зачем mono?
.Net Core уже не первый год существует.
slonopotamus
14.12.2022 09:56-2"Существует" и "готов к продакшену" - немного разные вещи.
ColdPhoenix
14.12.2022 10:45+1Так, а в чем проблемы(кроме UI)? использую не на одном десятке серверов и проектов, отлично живет(да и уже по сути .Net Core снова стал .Net, начиная с 5).
Mono в свое время оставил плохие впечатления.
trofian
14.12.2022 10:02+3dot net 7 кроссплатформенный и open source, это если вы про то что для него требуется windows. Если нет поясните что вы имели в виду под MS серверным стеком
asd111
14.12.2022 14:33+1Если вы еще не смотрели .net 7 то очень рекомендую посмотреть https://dotnet.microsoft.com/en-us/download/dotnet/7.0 Он стал бесплатным, кроссплатформенным а исходники лежат на гитхабе. Разрабатывать можно в бесплатной версии visual studio под windows и при этом есть кросскомплияция бинарников под линукс и можно сформировать self hosted выполняемый файл и не ставить саму платформу .net на сервер как с тем же php.
В самом простом варианте проект на .net 7 выглядит вот так https://learn.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-7.0
Просто просмотрите сверху вниз и обязательно попробуйте. Сейчас благодаря asp net core разрабатывать веб на C# проще чем на том же php а результат работает в разы быстрее чем на php даже если использовать полноценную открытую ORM Entity Framework Core. А если вы использовали laravel то результат на asp net core будет выдерживать нагрузку в 10 и более раз выше.
Kengurogoff
14.12.2022 06:22+11Не нужно называть битрикс фреймворком. По сути это CRM, к которой прикрутили кучу функционала. К нормальным фреймворкам он имеет крайне опосредованное отношение.
Atton
14.12.2022 13:18Смешали кучу понятий
Может быть и CRM, и CMS, и фреймворк
Ели не видели в реальной жизни больших проектов, где Bitrix как фреймворк используется, то это не значит что они не существуют
Vitaly48
14.12.2022 14:46+2Я могу понять использование битрикса как CMS из-за большего кол-ва готовых модулей для приёма платежей, расчёта доставки, интеграции со складскими системами и т.п., но вот использовать как фреймворк это странно. У него ведь ужасный код ядра, плохая документация и отсутствие какого либо дружелюбия к разработчику
Atton
14.12.2022 15:20-1На Bitrix не только интернет-магазины делаются.
Прекрасно работает на php8, что свидетельствует о решении многих проблем.
"Странно" это относительная оценка, а не факт. Факт в том что как фреймворк он работает.Код ядра читается, если в документации чего-то нет, IDE помогает. Документация не самая лучшая, согласен.
"Ужасный код" снова оценка. Есть отвратительные места в коде, а есть и отличные современные. "Ужасный" код легко находится и фреймворках и во всеми любимом WP.
Не стоит уверенно судить о том, чего в реальности не видели.
Vitaly48
14.12.2022 16:30+10У меня основные претензии к битриксу были такими:
Отсутствие взрослой системы накатывания обновлений. Все обновления накатываются через web интерфейс в котором может что угодно пойти не так. Плюс обновления не повторяемые, я не могу зафиксировать что мне нужно обновить до конкретной версии, через web интерфейс обновляется до последней возможно версии (поправьте если ошибаюсь). Это приводит к тому, что я как разработчик не могу протестировать обновление локально и накатить обновление условно через месяц т.к. за это время может выйти новая версия того или иного модуля.
ORM которая не ORM, а просто набор классов для работы с БД. В нормальных ORM мы манипулируем записями БД как объектами, но не в битриксе, в битриксе только массивы.
P.S. Как решение можно использовать сторонние пакеты вроде этого https://github.com/sheerockoff/bitrix-entity-mapperОтсутствие вменяемой документации. D7 анонсировали около 8 лет назад, но до сих пор документация находится в плачевном состоянии.
Несоблюдение стандартов разработки, весь код написан в стиле который идёт в разрез со всем PHP сообществом. В коде используются короткие открывающие теги PHP, методы классов вызываются как статические хотя таковыми не являются, PSRы не соблюдаются, отсутствует единая точка входа, composer не используется
Сам битрикс не заточен на контейнеризацию, опять же это следствие нескольких факторов:
1.стандартные модули поставляются не через менеджер пакетов composer
2. обновления накатываются через web интерфейс
3. редактирование некоторых настроек приводит к изменению файлов, а эти изменения затираются после передеплояу разработчиков битрикса постоянное желание писать свои решения, хотя можно использовать сторонние пакеты которые уже стали стандартом в разработке. Тогда бы разработчики не плевались от отсутствия документации и получали бы релевантный опыт
Это всё что удалось быстро вспомнить (т.к. давно не работал), но если надо могу долго продолжать описывать минусы с которыми сталкивался при разработке на битриксе. Всё эти минусы простительны когда мы говорим о битриксе как о CMS, т.к. CMS ориентированы на пользователей, но при позиционировании его как фреймворка такие проблемы сложно игнорировать, потому что фреймворк ориентирован на разработчиков и должен помогать в написании кода, а тут получается что разработчику приходится бороться с фреймворком пробираясь через тернии документации и легаси кода
BXVoral
15.12.2022 12:51ORM которая не ORM, а просто набор классов для работы с БД. В нормальных ORM мы манипулируем записями БД как объектами, но не в битриксе, в битриксе только массивы.
это не совсем так. Точнее это (только массивы) будет устаревшим подходом. fetchObject, fetchCollection и вперед....
BXVoral
15.12.2022 15:45Код ядра: а вы не смотрите :) Если серьезно, вы же не смотрите в код всех программ и инструментов, все равно оцениваете именно то, как оно выполняет свою работу.
Документация и "дружелюбие"... Относительное понятие - когда мало работаешь или пытаешься освоить - может быть.
У меня есть свой проект и осознанно выбрал Битрикс. (конечно сыграло роль, что и по основной работе именно с битрикс проектами работаю). но.. У меня проект это SaaS. Более конкретно упрощенный САПР. Битрикс в первую очередь дал мне быстрое создание сайта, интеграции с платежными системами и т.п. в общем как инструмент донести информацию до пользователя и обеспечение взаимодействия с ним. Т.е. тут вообще на это потрачено минимум времени...
Далее идет уже тот самый модуль являющийся сутью проекта. Фреймворк Битрикс используется только на инфраструктурном уровне: там контроллеры для аякса, контроллеры для нового роутинга битрксового, репозитории (работа с ОРМ инфоблоков), классы таблиц - по сути тоже работа с ОРМ, но только уже со своими таблицами БД, ну и все возможные агенты (что по сути контролеры для CLI), работа с настройками... ну в общем все взаимодействие с апи битрикс.
Все это легкое, без какой то тяжелой логики. Все уже в сервисах.... Т.е. условно говоря, мне не проблема все перенести на симфони, ну или иной фреймворк. И будет доработан именно и только инфраструктурный слой с легкими классами.
И даже если бы писал "с использованием симфы" - все бы оставил точно так же - без взвешенной необходимости сильно завязывать на какой либо фреймворк это, на мой взгляд, не правильно...
В общем если обсуждать с точки зрения "пользователя-разработчика". Инструмент как инструмент, строить все на массивах не заставляет. А писать плохой код можно хоть на симфони хоть как. Тут от "программиста" зависит.
Симфони, кстати, тоже использую. Точнее консоль от нее - некоторую автоматизацию разработки реализовал для удобства.
BXVoral
15.12.2022 15:52Ну и как вероятное развитие. Часть проекта (уже где идет непосредственная работа пользователя с сервисом) - прям напрашивается SPA. Как знать, может психану :) И весь фронт вообще на vue + node.js переделаю. (все равно однажды надо дизайн сделать "приличный" вместо шаблонного из коробки).. Вот и получится, что от битрикса останется только бизнеслогика и админка. Стоит ли переписывать это все когда у меня по основному модулю работы по определению не могу быть ни когда закончены - там "фишек" хоть обвнедряйся"?
Kengurogoff
15.12.2022 07:08+2Ели не видели в реальной жизни больших проектов, где Bitrix как фреймворк используется
Весьма категоричное суждение - "если ваше мнение не совпадает с моим, значит вы ничего в жизни не видели".
Мне доводилось работать с корпорталами для госорганизаций, на несколько тысяч человек. Не знаю, считается ли это "большими проектами" в вашей системе ценностей; однако контракты там крутились миллионные, и под определение "интернет-магазин" они точно не попадают.
Так вот. Туда смогли вкрутить git, composer, самописную систему миграций и много чего еще. Словом, все практики нормальной разработки, которые по-умолчанию реализованы во фреймворках, но отсутствуют в битриксе. Собственно, от изначального "коробочного" решения там осталось разве что ядро (и то было перепилено в нескольких местах).
О чем это говорит? При наличии грамотных разработчиков (и миллионных контрактов) можно сделать практически что угодно. Стал ли от этого битрикс фрейморком? Думаю, нет.
Atton
15.12.2022 10:17Категоричность не я ввел в диалог. Предлагаю почитать определение понятия фреймворка сначала.
Предлагаете меряться проектами? Конкретика под NDA, но что то вы назвали "большими проектами" для нас обыкновенная каждодневная рутина. Как минимум это разного рода ЛК, аукционные площадки и другие узконаправленные бизнес-сервисы.
Смогли "вкрутить git, composer, самописную систему миграций и много чего еще" это все много лет как стандарт разработки и инструменты, не нужно пугать людей. Что-то есть из коробки, что-то ставится поверх. Это все прекрасно работает. Как и инструменты типа rector, phpstan, phpunit и т.д.
Раз перепилили ядро, то изначально был выбран неверный путь архитектором.О чем это говорит? Вы просто не знаете актуального состояния инструмента.
BXVoral
15.12.2022 15:55Так ведь ни кто и не говорит что битрикс стал фреймворком. В битриксе есть фреймворк, который вполне можно использовать. Естественно брать Битрикс именно в качестве фреймворка для нового проекта - тут надо смотреть именно на возможности. Если существующие модули (как "бонус" к фреймворку) покрывают значительную часть планируемых работ почему бы и нет?
BeLord
14.12.2022 11:04Есть такая штука стоимость владения решением. Возьмите бизнес задачу и опишите ее решение на стеке Х и на стеке Y, посчитайте во что обойдется владение в одном и в другом случае, например в течении 5-7 лет и сравните результаты. Можете получить, что "качество" языка программирования в принципе не важно.
Saty
16.12.2022 13:58А как же symfony? Отличный фреймворк, современны, мощный, насыщен современными лучшими подходами в вебе. А-ля спринг на пхп. Кроме него есть ещё несколько хороших фреймворков, которые отлично подходят для Энтерпрайза. Конечно же, есть свои нюансы, в целом, лучше, имхо, выбрать джаву или го. Но на пхп можно собрать не менее устойчивое и надёжное приложение. А в определённых ситуациях, даже, будут свои преимущества перед другими стеками.
evgsavosin
14.12.2022 10:02У каждого ЯП есть плюсы и минусы. Есть хорошие и качественные реализации, а есть плохие. Возводить что-то в абсолют, не снимая розовых очков, в корне неверно.
FanatPHP
14.12.2022 11:48+9Проблема РНР не в том, что он плохой, а в том что простой. На РНР, как и на любом другом языке, можно писать хорошо и можно писать плохо. Но из-за того что РНР очень прост в освоении, на нем реально может начать писать любая кухарка, освоившая HTML. Вот кухарки и пишут. А потом еще и начинают других учить. Но надо все-таки отличать кухарок от программистов. Которые прекрасно пишут на РНР отличный код.
А дальше все просто — о языке судят по таким вот кухаркиным программам и книжкам. Если взять наугад какое-нибудь руководство по РНР или ответ со Stack Overflow, или какую-нибудь программу, которую начали писать еще в прошлом веке — например Wordpress — то там все так и будет — код плохой, авторам стыдно. Но вот делать вывод о том что РНР "лучше не использовать" — вот это будет уже глупость. Надо просто самому не быть макакой, а учить программирование. Тогда и язык вдруг станет нормальным.
Arris
14.12.2022 15:59+1Мы все понимаем, что Wordpress (а еще MediaWiki итд итп) хорошо бы переписать с использованием современных практик.
Но кто этим будет заниматься? И кому это нужно? (риторические вопросы)
Arris
14.12.2022 15:57+1Все началось со статьи "PHP: фрактал плохого дизайна" (*). Понятия не имею, что хотел сказать автор, называя так статью - но он был из тех танцоров, которым мешают яйца.
С тех пор прошло много лет. Как бы не десять, да.
Язык очень серьезно изменился.
PHP тех лет и PHP нынешний - это два совершенно разных инструмента.
Ситуация в некоторой степени усугубляется тем, что в сети все еще полно рецептов и рекомендаций использовать PHP неправильно. Вплоть до, да, рекомендаций использовать
mysql_connect(), эмулировать композер (потому что тогда композера ещё не было) или, прости господь (Тьюринг), не использовать классы в принципе. К счастью, сайты с такими советами совершенно естественным образом приказывают долго жить и исчезают.Но люди-то помнят! Помнят, что когда-то PHP был плохим, что его было модно ругать, а таковой ругающий в глазах окружающих обретал ореол некой особенной праведности!
P.S. (*) а может быть, и немного раньше - но популярной проблема стала, по моим наблюдениям, именно с этого фрактала.
Как-то так.
tommyangelo27
14.12.2022 16:55Оригинал "Фрактала" вроде был в 2012 году был написан. А я хорошо помню, как начинал в 2010 джуном на пхп, и активно сидел на форуме php.ru
И вот уже тогда вовсю были срачи о том, что PHP - отстой, и надо с него уходить на Ruby или Python.
SerafimArts
13.12.2022 20:51+13Душнила mode on =)
Раньше писать в них код и читать его можно было только в конструкторе
Нет, писать в них значения (один раз) и читать их можно было где угодно https://onlinephp.io/c/7a36c
Заголовок спойлера<?php class Test { public readonly string $title; public function init(): void { $this->title = 'some'; } } $t = new Test(); $t->init(); var_dump($t->title);Теперь вместо того, чтобы указывать тип mixed для аргументов в методах, можно просто перечислять необходимые типы через амперсанд.
Тоже нет. Это означает, что в PHP 8.2 можно использовать и конъюнкцию и дизъюнкцию одновременно. Раньше можно было использовать либо одно (И), либо другое (ИЛИ). Более того, любая подобная форма так же подвержена правилам Барабары Лисков:
abstract class ParentClass { abstract public function test(): (A&B)|null; } class ChildClass extends ParentClass { public function test(): A&B {} }Это изменение единогласно приняла вся команда разработчиков PHP, так как в ядре PHP есть методы, классы и функции, которые возвращают false или true.
Не совсем. Вначале речь в обсуждении (если не путаю) шла о добавлении
true, т.к. уже был отдельноfalse(который использовался в stdlib часто из-за СИшного легаси апи). Для того, чтобы просто привести систему типов к единообразию (а не для каких-то практических целей).А выделение подобных типов в standalone было сделано для того, чтобы их можно было сужать по LSP:
// parent public function request(): Response|false; // child public function request(): false;И вроде как даже в отдельном обсуждении было.
Теперь можно передавать в методы iterator_() тип \Traversables
И раньше можно было. А сейчас можно
iterable(т.е. входящие аргументы\Traversableзаменили наarray|\Traversable).Да и проверять на тип раньше тоже не обязательно было, можно было просто
count([...$iterable])писать вместоcount+iterable_countдля разных типов. Просто это работало долго.
1Tiger1
14.12.2022 01:53так, я не понял, и что ни одного комментария в духе "а что на нём кто то ещё пишет?" ?
где я вас спрашиваю холивары?
да, хабр уже не торт.
maeris
14.12.2022 08:08+8Вот и представьте, насколько умер язык, что даже холивары на тему "кто на нём вообще пишет" устарели!
tukreb
14.12.2022 10:42-6Скорее хабр не торт после февраля. Вы посмотрите с каким опозданием новость появилась об новой версии. Всякие дайджесты об php уже наверно как пол года никто не делает, да и не только по php, а вообще по любому языку. Такое чувство, что только переводчики тут остались.
NikitchenkoSergey
14.12.2022 11:08+3Если интересуют дайджесты по php - их можно найти здесь: https://t.me/phpdigest
FanatPHP
14.12.2022 12:12+1PHP резко просел по популярности в 2022, я прямо вижу это невооруженным взглядом. Но это ему пошло на пользу. На Тостере все вопросы из серии "я не понимаю, что мне надо, но мне надо это прямо сейчас!!" ушли в питон. РНР остался обычной рабочей лошадкой, на которой делают сайты.
Vitaly83vvp
14.12.2022 14:00С readonly для меня непонятно. Почему не использовать getter/setter? Фактически, readonly поля - это private поля + getter'ы.
Rsa97
14.12.2022 16:22+3readonly-свойство инициализируется только один раз и только из той области, в которой оно задано. После этого значение зафиксировано и не может меняться. Значение же в приватном свойстве можно переписать.
Vitaly83vvp
14.12.2022 16:29Да, точно, не уловил нюанс. У меня были проекты, где можно было бы использовать их, но обходился обычным private. Это свойство, думается, будет полезным для больших проектах с множество разработчиков.
tommyangelo27
14.12.2022 16:57Супер удобно для внедрения сервисов-зависимостей, которые не предполагается менять, только вызывать их методы.
PeppyBear
15.12.2022 09:39-1Всё новое конечно хорошо)
…но бывает обновился, запускаешь свой движок который ты сам лет 10 назад начал писать и он оброс кучей всякий модулей - то одна функция под обновление, то другая отвалилась…
Это конечно касается исключительно только меня, и я все равно обновлюсь) а с ворнингами и деприкейтед методами полюбому жить…
Хотя было бы как для приложений andriod studio, само пометилось и предложило переписать везде в коде новую тему)
В любом случае - они молодцы, развиваютя)
namee
А перечислимые типы (enum) подвезли уже?
kirik
Да, в 8.1
namee
Отлично. Спасибо. Есть повод обновиться.