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

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

Как-то так?

if (is_string($anyVariable)){
	substr($anyVariable, 0, -1);
	$anyVariable .= ', but with PSR and wise use of PHPStan it will be pretty decent';
}

Просто если "да", то я наконец-то в #2021 стал "современным РНР разработчиком"))

Код написан не по PSR-12 так что все еще нет ༼ຈل͜ຈ༽

Matt Brown, автор статического анализатора Psalm, покидает Vimeo, где проработал 7 лет, и не будет заниматься PHP

оу :(

Интересно, что с Partial Function Application не так?

Может какие-нибудь иммутабельные классы можно было бы сделать, чтоб при изменении свойства создавался новый объект. Тогда бы и readonly свойства были не нужны.

Но ведь immutable class можно уже сейчас иметь. Достаточно не иметь публичных свойств и сеттеров.

Для ДТО-шек / структур данных это неудобно использовать.
А. Нужно делать все свойства приватными и генерировать геттеры.
Б. Если все-таки хочется на основе предыдущей создать новую структуру, то маппинг приходится прописывать вручную.
С А предлагают бороться readonly свойствами, А о Б вроде как и не задумываются...

чтоб при изменении свойства создавался новый объект

Не очень понятно, как это должно выглядеть для пользователя программиста.

$immutable = new Immutable('data');
$immutable->data = 'new data';

В какой переменной у нас окажется новый объект с измененными данными при таком вызове? + Это очень неявное поведение, больше похоже на бомбу замедленного действя. Люди будут пытаться работать с этим как с мутабельным объектом (потому что он выглядит и крякает как мутабельный объект) и это неизбежно будет приводить к фрустрации, когда они будут понимать, что в итоге оно не работает как они предполагали.

Не очень понятно, как это должно выглядеть для пользователя программиста.

Признаться, сам не знаю, поэтому и не написал пример. :) Слышал, что в ФП языках вроде можно что-то такое делать.


Люди будут пытаться работать с этим как с мутабельным объектом

Ну, так \DateTimeImmutable тоже крякает, как мутабельный объект.

Ну, так \DateTimeImmutable тоже крякает, как мутабельный объект.

Ну это не совсем правда. У него все это более явно прописано в сигнатурах мутирующих методов. А доступ к ним есть только в том случае, если вы явно знаете, что работаете с \DateTimeImmutable. Если у вас сигнатура \DateTimeInterface, а вы пытаетесь использовать это как \DateTime, а по факту там оказался \DateTimeImmutable - то вы ССЗБ. Если у вас сигнатура \DateTime - то, \DateTimeImmutable вы туда просто не передадите.

У него все это более явно прописано в сигнатурах мутирующих методов.

Методы-то те же: add, sub, setTimestamp и т.п. Если вы при этом считаете, что работаете с мутабельным объектом — это ваши проблема.


В общем можно отделить мутабельные от немутабельных объектов в php по явно указанным в имени классов суффиксам, но в момент непосредственной работы с объектом крякают они одинаково. И лично я не вижу тут проблемы. Т.к. всплывет она максимально рано и решается на уровне стандартов к написанию приложения.

Если вы при этом считаете, что работаете с мутабельным объектом — это ваши проблема.

Я считаю, что работаю с тем классом, который прописан в сигнатуре, не более. Какой там написан - так с ним и работаю.

Это вопрос соглашений об именовании. Вам придёт, например, инстанс \Symfony\Component\String\UnicodeString. Он мутабельный или иммутабельный? (Ответ: Иммутабельный, но по имени класса это не видно)

Нужно менять через линзу. Например в 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).

Мы точно один и тот же дайджест комментируем? Я вот про это

Радует что is_literal не приняли, непонятная штука получалась у них.

А что не так с 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 - нет.

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