Как стать автором
Обновить

Комментарии 50

Времена динозавров:

var $user;


Далее:

public $user;


Далее:

public int $user;


Наши дни:

public array|bool|callable|int|float|null|object|resource|string $user;
var $user; по прежнему работает. Даже в PHP 8.
Вот это немного напоминает нам
Улучшение английского
The European Commission has just announced an agreement whereby English will be the official language of the European Union rather than German, which was the other possibility.

As part of the negotiations, the British Government conceded that English spelling had some room for improvement and has accepted a 5- year phase-in plan that would become known as «Euro-English».

In the first year, «s» will replace the soft «c». Sertainly, this will make the sivil servants jump with joy. The hard «c» will be dropped in favour of «k». This should klear up konfusion, and keyboards kan have one less letter. There will be growing publik enthusiasm in the sekond year when the troublesome «ph» will be replaced with «f». This will make words like fotograf 20% shorter.

In the 3rd year, publik akseptanse of the new spelling kan be expekted to reach the stage where more komplikated changes are possible. Governments will enkourage the removal of double letters which have always ben a deterent to akurate speling. Also, al wil agre that the horibl mes of the silent «e» in the languag is disgrasful and it should go away.

By the 4th yer people wil be reseptiv to steps such as replasing «th» with «z» and «w» with «v».

During ze fifz yer, ze unesesary «o» kan be dropd from vords kontaining «ou» and after ziz fifz yer, ve vil hav a reil sensibl riten styl. Zer vil be no mor trubl or difikultis and evrivun vil find it ezi tu understand ech oza. Ze drem of a united urop vil finali kum tru.

Und efter ze fifz yer, ve vil al be speking German like zey vunted in ze forst plas.

If zis mad you smil, pleas pas on to oza pepl.

Из специфичного в своей простоте php, делают нечто вроде java. Типизации, либы, импорты, наследования, классы, компиляторы и т.д.
И почти как говорилось в этом мемасике "давайте примем как стандарт пхп, улучшим его и через пять лет мы будем все писать на яве как изначально и предполагалось"
Наши дни:
public mixed $user;
По моему мнению, в попытке реализовать различные улучшатели языка, в 8 версии они перегнули палку и очень сильно усложнили PHP, почти до полного нежелания его использовать.
Просто взяли (очень) немного фич из нормальных языков.

Надеюсь в php-cs уже подготовили правила для disable unions. Если необходим общий функционал — надо выносить в интерфейсы/трейты. На данный момент выглядит как шаг назад в плане типизации. Если у кто-то может рассказать, в каких случаях union будут лучше интерфейсов/трейтов — буду рад услышать в комментариях

Я думаю, что логика добаления unions такая-же, как изначально в TypeScript — возможность типизировать существующий код, например библиотеки, не ломая обратную совместимость.
Если необходим общий функционал — надо выносить в интерфейсы/трейты.
Непонятно, причём тут трейты/интерфейсы. Как с помощью них реализовать, допустим, вот такую функцию?
function isPositive(int|float $value): bool {
    return $value > 0;
}

Объясните непрограммисту, почему вариант if (isPositive($value)) это более предпочтительная конструкция чем if ($value > 0)?

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

isPositive это просто абстрактный пример. Причём довольно простой. Поэтому вместо него вполне можно использовать «инлайновую» проверку if ($value > 0). Хотя иногда даже простой код приходиться оборачивать в функцию чтобы реализовать интерфейс или передать в качестве функции обратного вызова в другой сервис.

Представьте, что вы пишете валидатор. Именно он должен реализовывать весь функционал, а уж насколько конкретный функционал банален — дело вторичное. Важно, что у вас происходит выделение логики валидации в отдельную абстракцию.

Если однострочная функция возвращает bool, это не значит, что она будет использована в if. Она может быть предназначена для использования в качестве колбэка в функции сортировки или фильтрации, в т.ч. находясь при этом в другом классе или неймспейсе.

Если вы «играете в типизацию», то необходимость реализовывать такой код говорит о неверной архитектуре проекта. Если вам нужно проверить, положительный ли баланс на карте клиента, то очевидно это будет `isPositive(float $balance)`. И напротив, если вам нужно проверить, совершеннолетний ли человек, то это будет `isLegalAge(int $age)`. А все остальное — плохая архитектура. ИМХО.

А если у вас универсальный валидатор, то, видимо, надо будет как в go писать вот так:


isPositiveInt(int $value)
isPositiveFloat(float $value)


Да?


На самом деле то, о чем говорите вы, должно строиться как бизнес-логика над имеющейся абстрактной моделью. Т.е. isLegalAge(int $age) внутри должно вызывать isPositiveInt(int $value). Но на самом деле не только, так как legal age для сигарет, вступления в брак и покупки алкоголя может отличаться. Так что первым делом вы проверите общую валидность, а вторым специфическую для конкретных условий.

В go не силен, писал пару мелких сервисов для себя, но глубоко не погружался, не могу ответить.
Насчет того, что isLegalAge должен внутри вызывать isPositiveInt — это выглядит как ненужное усложнение, как по мне — это самостоятельная реализация. А если нужны именно проверки на позитивность, то пожалуй да, оно так и должно выглядеть.

Если мы говорим об абстрактных валидаторах, которые не знают, что в них приходит (например, а-ля валидация ларавеля), то mixed и объединения типов кажутся хорошим вариантом. Но если говорить о бизнес-логике, имхо она должна быть конкретной, и в этом случае mixed уже выглядит как костыль для ослабления для каких-то кейсов, сходу так и не придумаешь даже.
Если мы говорим об абстрактных валидаторах, которые не знают, что в них приходит (например, а-ля валидация ларавеля), то mixed и объединения типов кажутся хорошим вариантом. Но если говорить о бизнес-логике, имхо она должна быть конкретной

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

А если мне просто нужно узнать что число положительное? Например, для какого нибудь универсального валидатора или библиотеки ассёртов. Использование union типов позволяет обойтись без mixed типа. Пример.

В соседнем комментарии как раз ответил. Возможно, мне стоило уточнить, что мой комментарий относился к бизнес-слою приложения, а не к валидации реквестов, например. Пожалуй в валидаторах или ассертах действительно это имеет право на жизнь.

Практически любым инструментом можно воспользоваться неправильно. Те же трейты могут сильно захламить код, если их использовать не в дополнение, а вместо dependency injection.

Не, ну материал, естественно, полезный. Но не тогда, когда уже было 1000 раз уже...


Каждая новая неделя и новый пост "Что нового в PHP 8". Действительно, ведь никто ещё не видел подобных постов на хабре, новинка (сарказм)!

Судя по минусу — я не прав и вы действительно не видели подобных публикаций раннее.


Да, соглашусь, возможно я погорячился, написав "каждую неделю" и у меня уже глаз замылился. В любом случае, для тех кто не видел — можете ознакомиться с материалами за последние 3-4 месяца:


Много чего позаимствовано из C#, что не может не радовать.

В параметрах списка теперь допускается опциональная висящая запятая
parameter list переводится как список параметров.

method_with_many_arguments(
    1,
    2,
    3,
    4,
);
Висячие запятые при вызове методов и функция были добавлены ещё в PHP 7.3 (RFC)
В 7.3 включили только для вызова функции. В 8.0 добавляют для описании функции.
Вопрос, эта висячая запятая только для того чтоб diff был поменьше?
Для однообразия. В массивах уже давно так можно. Редактировать удобней. Можно добавлять/удалять аргументы не отвлекаясь на эту запятую.

И таки для diff тоже.

Читал как то статью на хабре, где автору не нравится во что превращается PHP.

А я скажу, что прям в точку все попадает, и «Возвращаемый тип static » и "$object::class" и "?->", да и много других вещей, так не хватало в PHP, не раз сталкивался с такой необходимостью, теперь код можно будет писать более чисто, без личшних замудренностей!

Интересно, а так прокатит?


function calculateDistance(int x1, int y1, int x2, int y2){...}

$c = [['x1', 1], ['x2', 2], ['y1', 3], ['y4', 4]];
echo calculateDistance($c[0][0] : $c[0][1], $c[1][0] : $c[1][1] .....);

Надеюсь, что нет.

Можно будет как в js, через деструктуризацию, тут подробней

function calculateDistance(int x1, int y1, int x2, int y2){...}

$c = [ 'x1' => 1, 'x2' => 2, 'y1' => 3, 'y2' => 4];
echo calculateDistance(...$c);

Это несколько про другое всё же.

Не должно, так как именованный параметр не являет собой string. Оно бы так, как у вас, потенциально сработало, если бы в стандарте было calculateDistance('x1': 1, 'x2': 2 .....). Уже, кажется, где-то обсуждалось.

Чет не много полезного. Для себя нашел только mixed, match и именованные аргументы. Но JIT наверное порадует.
Добавлена поддержка оператора nullsafe (?->)

Вот это просто огонь. Очень актуально, например, при работае с DOM-парсерами
пока не могу придумать для чего нужны юнионы и абстрактные приватные методы в трэйтах?
Всё это вкусовщина, лишь бы на собеседованиях не спрашивали
РНР комбайн становится всё больше и больше… Может стоит всё таки заняться его аппроксимизацией? Придумывать ради того чтобы придумывать.

Если не секрет, что означает сей неологизм в контексте вашей реплики: "аппроксимизация"?

Извиняюсь, имел ввиду аппроксимация
но слово получилось забавное, подходит ко многим случаям, например, «аппроксимизация медицины»
А можете объяснить, чем атрибуты принципиально лучше phpDoc-ов, если всё равно используется рефлексия?
  1. Тем, что это стандартизованная часть языка.
  2. Тем, что это эффективнее, так как парсер за один (с оговорками) проход собирает всю эту информацию, и нет необходимости в файловом кэше и громоздких парсерах уровнем ниже.

P.S. А что еще как не рефлексию здесь надо было использовать? Ведь рефлексия — это не что иное, как получение метаданных, связанных с объектом. Как иначе сделать? Вы, конечно, можете это скрыть за какой-нибудь языковой конструкцией, но внутри все равно будет механизм рефлексии.

т.е. получение через рефлексию атрибутов будет быстрее работать, чем получение phpdoc через ту же рефлексию?

У вас вопросы только по части синтаксиса что ли? Если так, то phpdoc — это все-таки комментарии. Этот подход с самого начала критиковали за использование комментариев не по назначению. Поэтому логично, что на смену phpdoc придет языковая конструкция.


P.S. Предвидя возражение: технически, да # — тоже комментарий, но по факту использование этого символа для комментирования не одобрялось сообществом с давних времен. Так что его переосмысление будет только на пользу.

спасибо

В целом да. Но и там и там настолько незначительные времена, что смысла сравнивать их по скорости нет.

Кому интересно грубое сравнение производительности PHP7.4 и PHP8 bolknote.ru/all/php-74-vs-php-80a
PHP8 быстрее на 10% — 30%
оптимизирующий транслятор «Брейнфака», с загруженной в него задачей вычисления числа Пи.

О да! Прям стандартная для PHP задача.

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