PHP Дайджест № 196 (1 – 11 января 2021)

[shuchkin]

Спасибо, Роман

[Compolomus]

Слоники слоники, слоники....))
Наконец доку перенесли, есть места не переведены которые, либо вообще док отсутствует

[Irker]

8 лет назад в след за самим php, помогал в подготовке к переносу документации в git и адаптации под это дело сайта edit.php.net. За это время столь много воды утекло, и столько было попыток от разных людей, что я уже и не верил больше. Молодцы!

[topuserman]

По поводу enum: я ждал этого функционала уже более 5 лет, но в результате получаем не то, что ожидали.
Для чего вся эта мишура с трейтами и т. д?
Почему не сделать как в c++?

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

На мой взгляд php начал развиваться в не том направлении.
Слишком много уделяется внимание всяким бесполезным штучкам.
Взять нормальный функционал у одного языка, и сделать из него елку.

[pronskiy]

Ох, простите, что люди провели исследование енамов во всех популярных языках и в свое свободное время бесплатно сделали не то, что вы ожидали.

[topuserman]

если люди потратили время и сделали функционал, это же не значит, что функционал должен радовать всех ?

PS.: я не один ждал этого функционала, и те, кто ждал, сталкивались со сложностями, которые легко решались бы через enumerations.
и enum — нужен только для группировки набора значений и возможность принимать один из объявленных значений.

enum COLOR {
    RED = 1,
    GREEN,
    BLUE
}

function f(COLOR $color) { echo $color; }

f(COLOR::GREEN); // print 2
f(10); // fatal error

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

[topuserman]

Страшно представить, что будет с долгожданными дженериками.

[pronskiy]

Ничего не будет ¯\_(ツ)_/¯

[pronskiy]

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

В общем-то согласен, что это основное. А дополнительные плюшки — ну так про любые фичи можно сказать, что они усложняют код.

Для вдохновения взяты отличные языки (Kotlin, Swift, Rust), так что думаю в использовании будет отлично. https://github.com/Crell/enum-comparison#summary

[VolCh]

енумы часто текстовые (натуральные ключи) С таким синтаксисом есть гарантии что значения одного типа в енумк и могут быть переданы параметром в функцию с примитивным тайпхинтом string?

[Maksclub]

В PHP идет куда более мощная разработка АТД, чем вы ожидаете от простых скалярных перечислений

Примеры:
Match Enhancement: wiki.php.net/rfc/pattern-matching#match_enhancement
State machine: wiki.php.net/rfc/enumerations_and_adts#state_machine
Maybe Monade: wiki.php.net/rfc/tagged_unions#examples
Ваш простой вариант: wiki.php.net/rfc/enumerations_and_adts#primitive-equivalent_cases

Получается очень мощные штуки, которые даже в др языках с трудом пытаются вместить

[VolCh]

Почему не сделать как в c++?

Как в языке, который рассматривают в качестве варианта только для очень специфичных требований?

[Rukis]

По поводу enum: я ждал этого функционала уже более 5 лет, но в результате получаем не то, что ожидали.
Для чего вся эта мишура с трейтами и т. д?
Почему не сделать как в c++?

Вы забыли указать ссылку на ваш RFC пятилетней давности.

[arkamax]

Если вы осилили Xdebug, то вряд ли это имеет смысл

А как в наше время можно серьезно писать на PHP без Xdebug или чего-то сравнимого? Тем более, что в многих IDE его поддержка включена по умолчанию, и настройка — это не «осилил — не осилил», это где-то на уровне профпригодности на некотором среднем уровне. У нас даже джуны просят статью по настройке Xdebug и потом (объяснимо) жить без него не хотят.

[VolCh]

Можно. Даже если осилил. но эффективней получается через логи. А может отладка нужна на удалённом сервере. где все порты закрыты и вообще кубер какой-нибудь и отладчика в образе нет.

[pronskiy]

+ многим просто удобнее через var_dump, потому что быстро и ничего настраивать вообще не надо.

[arkamax]

С удаленным сервером согласен, конечно, хотя можно и туда xdebug прокинуть, но с его возможностями это потенциальная дыра, так что лучше только на stage и с применением средств защиты (туннели итп). Но про «серьезно писать» я имел в виду то, что в большинстве случаев разработка все же ведется в основном локально или как минимум в менее закрытых контекстах, и тогда установка xdebug или другого дебаггера довольно тривиальна (даже в докер, а может и тем более в докер, т.к. это вопрос двух-трех строк в конфиге).

Почему я еще так говорю — я вижу кучу локальных разработчиков с результатами, которые явственно показывают, что они не понимают, что происходит у них в коде (но проблемы видят). Спрашиваешь — «как так, ты что, ни разу не видел, что у тебя попадает в это поле?». Ответ — «нет, на всё var_dump() не повесишь» (отмазался, молодец). А потом мы удивляемся, что масса кода на PHP не выдерживает критики. Просто не надо долбить 65% стен (см. предыдущий комментарий) отверткой, это как минимум неэффективно.

[VolCh]

По эффективности спорно. Я видел множество раз как разработчики долбят step into внутри стороннего кода особо не вглядываясь в стейт — просто не умеют пользоваться отладчиком эффективно.