Вот тут оч интересный момент. Вчера значит отрицательные числа передавать можно было а сегодня уже нет и это "не меняет интерфейс". А что на счёт контрактов и обратной совместимости?

Лучше не шарить стэйт

Выпустим версию 2.0)

Ну то есть давай всеж не общие фразы и прочий булшит из разряда "меня так учили" или "где-то почитал"

И тот и другой вариант - процедуры, сайд эффекты и нарушение инкапсуляции

Конечно лучше просить объект что-то делать, а не назначать ему стейт. Но тут уж как есть

Если мы именно про изменение стэйта

Тут я думаю оч маленький процент людей либки делают, в основном они делают регрессии такими вот изменениями

Потому что как правило любители сеттеров не особо за потоками данных в системе следят

Проблема же не в сеттерах как таковых, и не в публичных свойствах.

А в том что контроля за данными нет, сеттеры могут создавать иллюзию этого контроля

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

окей, возвращаемся к вопросу. В какой момент сеттер перестает быть сеттером?

public function rename(string $name)
{
    $this->name = $name;
}

это сеттер или уже не сеттер?

Исходя из моего определения (вольного):
> Очевидно что сеттер - это метод, основное и часто единственное назначение которого - устанавливать значение внутренней переменной

Вот как выходим надежно за пределы этого определения, то уже и не сеттер. Я бы еще добавил, что сеттер одноименен со свойством.

Для меня - нет

а если нам надо обновить имя, дату рождения и еще чего-нибудь + по изменению таймстэмп или версию инкрементнуть? У тебя логика будет по сеттерам дублироваться или появится какой setVersion или setUpdatedAt?

то есть исходя из определения, мы "знаем" что внутри есть такая переменная и мы меняем ее как бы из вне.

но меня больше вот этот кейс интересует

так как обычно вот на этом у людей с их этими сеттерами все идет по одному месту

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