Комментарии 47
Схватился за сердце после нововедений PHP. Интересно я один такой, кому не нравится в какую сторону пошло развитие PHP ? Взять тот же enum: казалось бы простой тип, но нагородили вокруг него функционал классов. Страшно представить что будет творится и как это будет использоваться на проектах.
Вот честно, рукалицо.
Соглсен. Складывается ощущение, что из языка делают фреймворк, чтобы засунуть его в фрэймворк.
то не проще ли уже перейти на какой-нибудь Go в новом проекте?А Go причём? Это ещё более лаконичный ЯП. Go в крупной кодовой базе будет так себе. Примерно все остальные языки более выразительные.
Можно, но зачем?Так не применяйте эту асинхронность. Все остальные нововведения принимаются для выразительности или гарантий.
Жабостайл...
Ну почему же жабостайл сразу... Это, скорее, дань функциональному программированию.
А в Java enum's покалеченные немного.
Они там именно, что перечисления, чем и хороши. А для всяких странных вещей недавно `sealed class` из котлина спёрли :)
Так объекты как экземпляры перечислений в Java первыми и появились. В других языках перечисление делалось на базе примитивных типов и значением перечисления и было значение underlying-типа.
Оба решения имеют свои плюсы и минусы. В Java-стиле набор допустимых значений строго ограничен, если базируемся на значениях, то мы ограничены только underlying-типом.
Значит, на Python вам противопоказано смотреть - там уже давно enum не слишком отличается от классов.
Как по мне, очень даже неплохое нововведение.
Согласен. Некоторые нововведения кажутся избыточными.
Это тайный заговор, чтобы PHP-сты перешли на Go :-D
Что значит "простой тип"? Как int или string? Как вы себе это представляете, учитывая динамическую суть PHP?
Реализация в джава стиле для PHP самая адекватная, как по функционалу, так и по возможностям реализации.
Нет, гарантированно не один. От происходящего с PHP хочется схватиться за сердце, за голову, и за револьвер. Стоило перешагнуть порог седьмой версии и дать языку гигантский толчок, как начали один за другим появляться не самые полезные нововведения. К счастью, ничто не мешает их игнорировать и по прежнему писать простой и быстрый код. И пользоваться полезной частью новшеств языка, которые улучшают производительность.
прогресс уничтожает прогресс
осталось дождаться дженериков
Никита Попов с вами не согласен
https://github.com/PHPGenerics/php-generics-rfc/issues/45
https://habr.com/ru/company/skyeng/blog/543794/ -- см "Что по дженерикам в PHP?" секцию.
rjhdby — если пропустили. В целом, я думаю, ничего не изменилось.
сложно != принципиально невозможно
Внедрение в язык новой концепции - это и есть самое, что ни на есть, изменение модели языка. И это относится к любому языку.
Дело за малым - выбрать реализацию, которая даст лучший компромис между поломкой обратной совместимости, просадкой производительности и соответствием тому, какой функционал хотели получить.
Что касается конкретно PHP и дженериков, то одним из самых мною желанных следствием будет появление нормальных типизированных коллекций из коробки.
Вроде уже пришли к тому, что дженериков в языке не будет, только на уровне анализа внешними инструментами. Сложилось такое впечатление после какого то интервью с Никитой.
Внедрение в язык новой концепции — это и есть самое, что ни на есть, изменение модели языкаВовсе нет, это же какое-нибудь (уродливое) «declare(strict_types=1)». Дженерики могут быть лишь дополнительной проверкой типа на стадии выполнения, то есть это просто расширение райнтайм проверок типов. Но из-за модели языка всё будет довольно странно, неконсистентно.
Вообще рантайм проверки типов — это очень странно. Их бы убрать, внедрить дженерики как везде, и пусть сторонние инструменты проверяют на стадии сборки.
Подобные статьи надо предварять обширным разделом "нафига оно вообще надо", потому что из текста я так и не понял, чем для реализации перечисления не подходил обычный ассоциативный массив.
// До
class BlogPost
{
public function __construct(
public string $status,
) {}
}
// После
class BlogPost
{
public function __construct(
public Status $status,
) {}
}
Это нужно для контроля типов. Так уж получилось, что в язык его начали добавлять и мое имхо это круто. Да, приходится менять привычки.
Контроль типов конечно бывает полезным, вот только назвать перечисление отдельным типом данных можно с большой натяжкой. По своей сути, ENUM это неизменяемый массив, поэтому и реализовывать его логично через массив, а не городить особые структуры. Кроме того, это разумно с точки зрения дальнейшей поддержки проекта: когда Ваше начальство вдруг решит, что в BlogPost должно быть не 5, а 100500 статусов, и каждый пользователь ещё может добавлять свои - меньше переделывать. Так что эту привычку я пожалуй пока менять не буду.
Суть в том что Вам достаточно объявить тип Enum чтобы исключить "левые статусы" и это будет контролировать PHP, а также сократит код на проверку существования передаваемых статусов. PostBlog возможно не самый лучший пример для Enum. Для 100500 статусов я думаю лучше найти другое решение.
Сейчас делается так (минимальный пример, по хорошему статусы надо вынести в какой-нить трейт, если они будут использоваться не только в этом классе)
<?php
class Blog
{
const STATUS_ACTIVE = 1;
const STATUS_DISABLE = 2;
static function getStatuses()
{
return [
self::STATUS_ACTIVE => 'Включено',
self::STATUS_DISABLE => 'Выключено',
];
}
}И в случае, когда потом надо переделать на статусы, которые будут создавать юзеры или еще какие-то, то в функции Blog::getStatuses() просто делается запрос в базу (условно) и получаются все новосозданные статусы, так как теперь (по правкам) их создают юзеры (в базе предварительно будут созданы статусы 1 - включено, 2 - выключено). Правки тут получаются минимальны и логика всех текущих кусков кода не ломается, только данные теперь не берутся из базы и можно спокойно править дальше. Как быстро провернуть такое с Enum - вопрос.
Стоило бы ещё добавить экспорт внутренних классов, как в Java, чтобы не плодить файлы.
Как быстро провернуть такое с Enum — вопрос.Не всё нужно делать быстро. Иногда стоит делать долго. В работе программиста и так очень много транзакционных издержек.
вот только назвать перечисление отдельным типом данных можно с большой натяжкой. По своей сути, ENUM это неизменяемый массив, поэтому и реализовывать его логично через массив, а не городить особые структуры.
По своей сути enum это набор констант связанных одним типом.
Кроме того, это разумно с точки зрения дальнейшей поддержки проекта ...
С описанной вами точки зрения лесом идет любая типизация и в целом ооп.
На практике же всегда находится компромисс и если где то по логике напрашивается enum и вероятность, что это в ближайшее время переродится во что то иное - низкая, то собственно и используется enum. И даже если когда то будет решено дать пользователям расширять, условно, список статусов, то мы, по крайней мере, вплоть до этого момента будем контролировать тип, пользоваться благами ide, автодополнением, авторефакторингом, стат анализом и тп.
Хорошее нововведение, жаль что так поздно
Всегда использовал BenSampo\Enum\Enum , и проблем с этим не было, уже есть куча пакетов для этого, зачем внедрять это в php не понимаю. лучше развивали язык на асинхронность, параллельность
enum Status: string implements HasColor
Опечатка?
Перечисления в PHP 8.1