Comments 50
var $user;Далее:
public $user;Далее:
public int $user;Наши дни:
public array|bool|callable|int|float|null|object|resource|string $user;
var $user; по прежнему работает. Даже в PHP 8.
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;beyondco.de/course/whats-new-in-php-8
Надеюсь в php-cs уже подготовили правила для disable unions. Если необходим общий функционал — надо выносить в интерфейсы/трейты. На данный момент выглядит как шаг назад в плане типизации. Если у кто-то может рассказать, в каких случаях union будут лучше интерфейсов/трейтов — буду рад услышать в комментариях
Если необходим общий функционал — надо выносить в интерфейсы/трейты.Непонятно, причём тут трейты/интерфейсы. Как с помощью них реализовать, допустим, вот такую функцию?
function isPositive(int|float $value): bool {
return $value > 0;
}
Объясните непрограммисту, почему вариант if (isPositive($value)) это более предпочтительная конструкция чем if ($value > 0)?
В общем случае функции полезны тем, что позволяют переиспользовать код и делать его более читабельным.
isPositive это просто абстрактный пример. Причём довольно простой. Поэтому вместо него вполне можно использовать «инлайновую» проверку if ($value > 0). Хотя иногда даже простой код приходиться оборачивать в функцию чтобы реализовать интерфейс или передать в качестве функции обратного вызова в другой сервис.
Представьте, что вы пишете валидатор. Именно он должен реализовывать весь функционал, а уж насколько конкретный функционал банален — дело вторичное. Важно, что у вас происходит выделение логики валидации в отдельную абстракцию.
Если однострочная функция возвращает bool, это не значит, что она будет использована в if. Она может быть предназначена для использования в качестве колбэка в функции сортировки или фильтрации, в т.ч. находясь при этом в другом классе или неймспейсе.
А если у вас универсальный валидатор, то, видимо, надо будет как в go писать вот так:
isPositiveInt(int $value)
isPositiveFloat(float $value)
Да?
На самом деле то, о чем говорите вы, должно строиться как бизнес-логика над имеющейся абстрактной моделью. Т.е. isLegalAge(int $age) внутри должно вызывать isPositiveInt(int $value). Но на самом деле не только, так как legal age для сигарет, вступления в брак и покупки алкоголя может отличаться. Так что первым делом вы проверите общую валидность, а вторым специфическую для конкретных условий.
Насчет того, что isLegalAge должен внутри вызывать isPositiveInt — это выглядит как ненужное усложнение, как по мне — это самостоятельная реализация. А если нужны именно проверки на позитивность, то пожалуй да, оно так и должно выглядеть.
Если мы говорим об абстрактных валидаторах, которые не знают, что в них приходит (например, а-ля валидация ларавеля), то mixed и объединения типов кажутся хорошим вариантом. Но если говорить о бизнес-логике, имхо она должна быть конкретной, и в этом случае mixed уже выглядит как костыль для ослабления для каких-то кейсов, сходу так и не придумаешь даже.
Если мы говорим об абстрактных валидаторах, которые не знают, что в них приходит (например, а-ля валидация ларавеля), то mixed и объединения типов кажутся хорошим вариантом. Но если говорить о бизнес-логике, имхо она должна быть конкретной
Ну так о чем и речь, что вы смешали в кучу бизнес-логику и абстракцию. Конечно, в большинстве случаев для бизнес-логики юнионы являются скорее ошибкой проектирования. Хотя, наверняка, и там можно найти пример, где это не так.
Практически любым инструментом можно воспользоваться неправильно. Те же трейты могут сильно захламить код, если их использовать не в дополнение, а вместо dependency injection.
Не, ну материал, естественно, полезный. Но не тогда, когда уже было 1000 раз уже...
Каждая новая неделя и новый пост "Что нового в PHP 8". Действительно, ведь никто ещё не видел подобных постов на хабре, новинка (сарказм)!
Судя по минусу — я не прав и вы действительно не видели подобных публикаций раннее.
Да, соглашусь, возможно я погорячился, написав "каждую неделю" и у меня уже глаз замылился. В любом случае, для тех кто не видел — можете ознакомиться с материалами за последние 3-4 месяца:
- https://habr.com/ru/company/otus/blog/524990/
- https://habr.com/ru/company/otus/blog/524270/
- https://habr.com/ru/post/524040/ (раздел "материалы")
- https://habr.com/ru/post/522042/ (раздел "аудио/видео")
- https://habr.com/ru/post/516984/ (частично)
- https://habr.com/ru/post/515216/ (только про JIT)
- https://habr.com/ru/post/511266/
- https://habr.com/ru/company/otus/blog/509598/ (опять про JIT)
- https://habr.com/ru/post/504906/ (косвенно)
- https://habr.com/ru/post/504356/
- https://habr.com/ru/news/t/510522/ (косвенно)
- и так далее
В параметрах списка теперь допускается опциональная висящая запятаяparameter list переводится как список параметров.
Висячие запятые при вызове методов и функция были добавлены ещё в PHP 7.3 (RFC)method_with_many_arguments( 1, 2, 3, 4, );
А я скажу, что прям в точку все попадает, и «Возвращаемый тип 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] .....);Надеюсь, что нет.
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 .....). Уже, кажется, где-то обсуждалось.
Добавлена поддержка оператора nullsafe (?->)
Вот это просто огонь. Очень актуально, например, при работае с DOM-парсерами
- Тем, что это стандартизованная часть языка.
- Тем, что это эффективнее, так как парсер за один (с оговорками) проход собирает всю эту информацию, и нет необходимости в файловом кэше и громоздких парсерах уровнем ниже.
P.S. А что еще как не рефлексию здесь надо было использовать? Ведь рефлексия — это не что иное, как получение метаданных, связанных с объектом. Как иначе сделать? Вы, конечно, можете это скрыть за какой-нибудь языковой конструкцией, но внутри все равно будет механизм рефлексии.
У вас вопросы только по части синтаксиса что ли? Если так, то phpdoc — это все-таки комментарии. Этот подход с самого начала критиковали за использование комментариев не по назначению. Поэтому логично, что на смену phpdoc придет языковая конструкция.
P.S. Предвидя возражение: технически, да # — тоже комментарий, но по факту использование этого символа для комментирования не одобрялось сообществом с давних времен. Так что его переосмысление будет только на пользу.
В целом да. Но и там и там настолько незначительные времена, что смысла сравнивать их по скорости нет.
PHP8 быстрее на 10% — 30%
PHP 8 — пробуем новые возможности