Про новое в PHP 8

[kudashevs]

Всем доброго времени суток,

А кто-то пробовал уже новые фишки из PHP 8? Я тут потыкал немного и весьма впечатлен. Особенно впечатляют property promotion (делают код значительно короче), union types (дают гибкость типизирования), nullsafe operator (хотя на первый взгляд это кажется злом, но для работы с legacy может оказаться просто отличным решением), match expression. И больше всего на меня впечатление призвел WeakMap класс, с ним можно просто творить чудеса А вы уже смотрели, щупали, что скажете?

 

[флоппик]

Мне очень странно, когда говорят про Union Types в контексте "гибкость типизирования". В пхп это не объединяющий тип, создающий новый тип, это просто логическое "или", которое ничего хорошего для строгой типизации не делает, а скорее наоборот. Да, union types __нужны__ в пхп, чтоб уменьшить всякие mixed, но это касается только примитивных типов, которые не объектные вообще.

 

[kudashevs]

Про гибкость типизирования имел ввиду возможность применения Union type в качестве указания типа свойствам. Искусственный пример:

class Reporter
{
    private string|\Stringable $value;

    /* код */
}

С натяжкой, но это можно назвать типом, хоть и просто через логическое "или".

И полностью согласен, что именно для строгой типизации тут ничего хорошего нет. Для непримитных типов это скорее зло, потому то теперь можно делать такие смеси "ежа с ужом" и стрелять себе прямо в SRP, что местами просто страшно становится

 

[Фанат]

Я человек простой, мне именно матч больше всего зашел.
Проперти промоушен - это надо Ректор заводить, вручную все переписывать заманаешься.

 

[kudashevs]

Я человек простой, мне именно матч больше всего зашел.

Новый match мне тоже понравился. Хотя там есть пару подводных камней, которые надо иметь ввиду:
- это не оператор как switch, а выражение, следовательно значение им будет возвращаться
- выражение использует строгое сравнение (===), в отличие от switch где было нестрогое (==)
- если ни одно из условий не сработало и отсутствует default выбросится ошибка \UnhandledMatchError

Мне кстати последний пункт не совсем прямо нравится, switch тут более гибкий (но и дает возможность писать более запутанный код).

 

[флоппик]

Про гибкость типизирования имел ввиду возможность применения Union type в качестве указания типа свойствам. Искусственный пример

С натяжкой, но это можно назвать типом, хоть и просто через логическое "или"

Я мог бы согласится с этой натяжкой, при условии что этому юниону можно было бы хотя бы присвоить альяс, что-то вроде:

type SerializedJson = \Stringable|string;

и использовать его хотя бы для обозначения семантики, типа private SerializedJson $string;
Иначе ты просто не знаешь, ты тот же самый имеешь ввиду тип "что-то похожее на строку" или вообще другой?

- если ни одно из условий не сработало и отсутствует default выбросится ошибка \UnhandledMatchError
Мне кстати последний пункт не совсем прямо нравится, switch тут более гибкий (но и дает возможность писать более запутанный код).

Это попытка сделать exhaustive match, вещь, которой кстати тоже в пхп сильно не хватало долго, и ее приходилось эмулировать через default: throw sth;
Без енумов я правда не уверен, что это сильно поможет, слишком легко ошибиться и узнать об этом только в рантайме.

 

[Фанат]

Хотя там есть пару подводных камней, которые надо иметь ввиду:

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

 

[kudashevs]

Возможно не так выразился про "подводные камни", тоже в первых двух пунктах вижу только положительное (поведение явно стало более ожидаемым). Про кидание ошибки, можно было сделать гибче, типа булевого флага (кидать или не кидать), хотя если остается switch, то собственно это и не нужно. Это так, моя вкусовщина

А про "подводные камни" имел в виду, что надо держать в голове, что выражение match это совсем о другом, это не про switch (просто согласно релиза может сложить впечатление, что они похожи, и в документации об этом довольно размыто сказано если сильно не вчитываться).

 

[grigori]

мне в комменте на хабре показали главный прикол 8ки - https://3v4l.org/rmN8l
у кого это выстрелит и сколько времени это надо будет расхлебывать - предсказать сложно

а остальное - отлично, мне и аннотации очень понравились, и property promotion - просто класс

 

[kudashevs]

мне в комменте на хабре показали главный прикол 8ки - https://3v4l.org/rmN8l
у кого это выстрелит и сколько времени это надо будет расхлебывать - предсказать сложно

Перечитал всю аргументацию связанную с этим примером, про ('' == 0). Мое скромное мнение, что хоть аргументация имеет рационально зерно, в данном конкретном случае несколько надумана.

- это мажорный релиз, который по semver может что угодно ломать без варнингов или нотисов (вот если бы в 7.5 такое бы сделали, тогда это выглядело бы действительно не комильфо)
- это изменение, которые действительно может жестко что-то поломать, указано на самом первом месте в списке вещей, которые обратно не совместимы (т.е. при выпуске версий эту проблему понимали и решили, что явно пора что-то с этим делать)
- на протяжении последнего десятилетия, может больше, всех призывают использовать строгое сравнение (===) в более или менее значимых местах.

Возможно что-то упускаю, но в чем вообще смысл сравнений как из примера

function cnt(){return '';}
if (cnt() == 0) echo 1;

, когда есть строгое сравнение или empty() или приведение к bool на худой конец? Или имеется в виду ранее определенное языком поведение, которому он должен следовать и на которое мы опираемся, а его потом берут и бесцеремонно меняют?

 

[AmdY]

мне в комменте на хабре показали главный прикол 8ки - https://3v4l.org/rmN8l
у кого это выстрелит и сколько времени это надо будет расхлебывать - предсказать сложно

а остальное - отлично, мне и аннотации очень понравились, и property promotion - просто класс

Вот и флоппик как раз озвучил недостаток с юнион типами, которые в будущем выльются в такую же проблему. Задолбали уже такие сырые фичи, которые потом несколько версий доводятся до ума, лучше бы уж оставались в phpdoc. В typescript на проектах вовсе запрещают использование юнионтайпов без выделение в отдельный тип.
С аннотациями тоже ещё надо щупать, чтобы не получилось как в ноде, где оказалось что нативные аннотации сильно проигрывают в скорости.

 

[флоппик]

Я скептичней всего относился к проперти промоушон сначала, типа, зачем нам альтернативный сахар опять, а сейчас смотрю на всякие Value Object и DTO через них сделанные, и прям читать приятеней сильно по быстрому их глазами.

 

[флоппик]

. Задолбали уже такие сырые фичи, которые потом несколько версий доводятся до ума, лучше бы уж оставались в phpdoc.

Я все же считаю, что такие юнион типы _немножко_ лучше, чем в некоторых местах вынужденная необходимость писать mixed. Может и дойдем до альясов на типы.

 

[grigori]

Возможно что-то упускаю

ты упускаешь ограничения кросс-доменного взаимодействия - обсуждать аргументацию стоит с автором аргументации, а не на другом сайте с другими людьми

 

[grigori]

в чем вообще смысл сравнений как из примера

function cnt(){return '';}
if (cnt() == 0) echo 1;

Проще говоря, непонятно во сколько денег обойдется компаниями обновление приложений для совместимости с 8кой.

Объем кода, который написан на php за 20 лет, исчисляется миллиардами строк, php - это 80% интернета.
Никто не знает, где это поведение использовалось, где вылезут ошибки при обновлении до 8ки. Перевести проекты с php 7 на php 8 всего за 3 года не получится.
Через 5 лет будем наблюдать ситуацию, что много проектов продолжет жить на php 7 просто потому что боятся переходить на 8ку и не хотят платить за обновление большие деньги.

 

[kudashevs]

ты упускаешь ограничения кросс-доменного взаимодействия - обсуждать аргументацию стоит с автором аргументации, а не на другом сайте с другими людьми

Да я как бы и не спорил и дискуссии разводить не собирался Просто изложил свое видение, и уточнил, не упустил ли чего-то значимого в своих рассуждениях.

в миллиардах строк кода, которые написаны за 20 лет - никто не знает, где это поведение использовалось

Логику понял, спасибо

 

[S.Chushkin]

...не хотят платить за обновление большие деньги.

"Большие" это сколько?

Из практики. Проект в 50 000 строк кода.
С 5.6 на 7.1 - 0.5 раб.дней затраты.
с 7.1 на 7.4 - 0.5 раб.дней затраты.

 

[grigori]

Можно пофантазировать. К примеру, большими можно назвать потери у владельцев проекта, а следовательно, и потери премий у руководства, которые вызваны переносом дат релиза всех новых фич на месяц, пока команда из ста человек обновляет систему на новую версию php. Это срок из моей практики обновления большой корпоративной системы с 5.4 на 7.0

Проекты на PHP на старых версиях обычно не застряют. Однако, при достаточном количестве несовместимых изменений принятие новой версии занимает много времени - например, переход на python 3 с 2ки занял в мире порядка 10 лет.

На данный момент основная сложность в том, что проблему с 0=='' не показывает ни один статический анализатор. Нужен анализатор, который, как минимум, покажет все сравнения с нулем, все сравнения с пустой строкой и все сравнения двух динамических вызовов. Можно попробовать создать feature request-ы.

Для нас проблема простая - через 5 лет мы будем видеть в вакансиях "php 7".

 

[флоппик]

Апну тему чутка,

Без енумов я правда не уверен, что это сильно поможет

Оказывается, РФЦ по енумам уже в обуждении: https://wiki.php.net/rfc/enumerations

 

[grigori]

из-за enum Никита хочет допилить поддержку объектов как ключей в массивах

PHP: rfc:object_keys_in_arrays

wiki.php.net