Комментарии 21
Как-то так?
if (is_string($anyVariable)){
substr($anyVariable, 0, -1);
$anyVariable .= ', but with PSR and wise use of PHPStan it will be pretty decent';
}Просто если "да", то я наконец-то в #2021 стал "современным РНР разработчиком"))
Matt Brown, автор статического анализатора Psalm, покидает Vimeo, где проработал 7 лет, и не будет заниматься PHP
оу :(
Интересно, что с Partial Function Application не так?
Слишком сложно получилось. Joe Watkins подробнее описал все у себя в блоге https://blog.krakjoe.ninja/2021/06/only-complete-applications.html
Может какие-нибудь иммутабельные классы можно было бы сделать, чтоб при изменении свойства создавался новый объект. Тогда бы и readonly свойства были не нужны.
Но ведь immutable class можно уже сейчас иметь. Достаточно не иметь публичных свойств и сеттеров.
Для ДТО-шек / структур данных это неудобно использовать.
А. Нужно делать все свойства приватными и генерировать геттеры.
Б. Если все-таки хочется на основе предыдущей создать новую структуру, то маппинг приходится прописывать вручную.
С А предлагают бороться readonly свойствами, А о Б вроде как и не задумываются...
чтоб при изменении свойства создавался новый объект
Не очень понятно, как это должно выглядеть для пользователя программиста.
$immutable = new Immutable('data');
$immutable->data = 'new data';В какой переменной у нас окажется новый объект с измененными данными при таком вызове? + Это очень неявное поведение, больше похоже на бомбу замедленного действя. Люди будут пытаться работать с этим как с мутабельным объектом (потому что он выглядит и крякает как мутабельный объект) и это неизбежно будет приводить к фрустрации, когда они будут понимать, что в итоге оно не работает как они предполагали.
Не очень понятно, как это должно выглядеть для пользователя программиста.
Признаться, сам не знаю, поэтому и не написал пример. :) Слышал, что в ФП языках вроде можно что-то такое делать.
Люди будут пытаться работать с этим как с мутабельным объектом
Ну, так \DateTimeImmutable тоже крякает, как мутабельный объект.
Ну, так \DateTimeImmutable тоже крякает, как мутабельный объект.
Ну это не совсем правда. У него все это более явно прописано в сигнатурах мутирующих методов. А доступ к ним есть только в том случае, если вы явно знаете, что работаете с \DateTimeImmutable. Если у вас сигнатура \DateTimeInterface, а вы пытаетесь использовать это как \DateTime, а по факту там оказался \DateTimeImmutable - то вы ССЗБ. Если у вас сигнатура \DateTime - то, \DateTimeImmutable вы туда просто не передадите.
У него все это более явно прописано в сигнатурах мутирующих методов.
Методы-то те же: add, sub, setTimestamp и т.п. Если вы при этом считаете, что работаете с мутабельным объектом — это ваши проблема.
В общем можно отделить мутабельные от немутабельных объектов в php по явно указанным в имени классов суффиксам, но в момент непосредственной работы с объектом крякают они одинаково. И лично я не вижу тут проблемы. Т.к. всплывет она максимально рано и решается на уровне стандартов к написанию приложения.
Нужно менять через линзу. Например в C# ввели неизменяемые записи record, которые можно "менять" только делая новую запись с помощью оператора with как то так.
$immutable = new Immutable('data');
$newImmutable = $immutable with {data = 'new data'};Ну вот в статье примерно это и написано да, что возможно сделают clone with. Это решит проблему, да.
Ну нет. В rfc Readonly properties 2.0 есть только примеры с предопределенными методами и ссылка на этот RFC https://externals.io/message/112624, который может когда-то и примут (а висит он с 2020 года - https://github.com/php/php-src/pull/6538).
А что не так с property accessors?
Как по мне, в не принятии на голосование есть логика.
В php нет разделения на поля (fields) и свойства (properties), как, например, в c#.
Добавление property accessors не явно делает это разделение.
Пример:class User {
public string $name { get; set; }
тут вроде бы всё ок, но если добавить кастомную логику, уже придётся добавлять новое приватное поле:class User {
private string $_name;
public string $name {
get {
return $this->_name;
}
set {
if (strlen($value) === 0) {
throw new ValueError("Name must be non-empty");
}
$this->_name = $value;
}
}
поскольку для php нет сосбой разницы между полями _name и name, становится не понятно почему _name может иметь значение, а name - нет.
PHP Дайджест № 207 (29 июня – 12 июля 2021)