Может парсер усложняет?

ну там и так кс грамматика вроде как

ну т.е. не знаю как на счёт похапешного LALR, но в примитивных комбинаторах не усложняет ничего

парсер сильно усложняет синтаксис << xxx >> - это да

хотя... не, вроде не усложняет

так для < тоже надо шифт нажимать

не, проблем с парсерами нет, даже с самыми примитивными

Наброшу, пожалуй))

Однажды я услышал, что геттеры — это плохо.

И прошел все этапы реакции по Кюблер-Росс: отрицание, злость, торг, депрессию, принятие 😂
Надеюсь, этот пост поможет пропустить несколько стадий.

DTO. Если тело геттера return $this->privateProperty, заменяем его публичным свойством с аннотацией @psalm-readonly-allow-private-mutation или @psalm-readonly или объявляем весь класс @psalm-immutable. Так мы обеспечиваем инкапсуляцию да ещё и нанооптимизируем код (-N вызовов геттеров). Метод без каких-либо манипуляций не имеет смысла — это 4 строки визуального долга и 1 строка для покрытия тестами.

Кстати, я тут заметил, что геттер — это трюк. К существительному добавили глагол, чтобы удовлетворить фомуле subject.actionVerb(?object). Вот только get — это не предоставить, а получить. То есть мы не просим объект поделиться состоянием, мы его отбираем.

Value Object. Если метод представляет собой query по CQS и возвращает некоторое представление (проекцию) объекта, то его название не должно быть шаблонным, оно должно отражать семантику. Например, Birthday::format(string $format): string, Color::toHex(): string.

Entity. Стараемся применять принцип Tell-Don't-Ask. Попробую сформулировать по-своему. Объект — это состояние + поведение. Если мы программируем объектно-ориентированно, мы должны просить объект совершить действие над принадлежащим ему состоянием, а не отбирать у него состояние и выполнять действие за пределами этого объекта. Если программируем не объектно-ориентированно (что тоже ок), то объекты по определению не используем и геттеры, соответственно, тоже.

---

Итак, в DTO вместо геттеров используем публичные свойства. В Value Object — семантические query методы, и то, если не добавлять "на всякий случай", их будет немного. В моделях оставляем только command методы.

Как тогда вывести состояние модели? Рассудим логически. Для вывода состояния поведение не нужно, нужно только состояние. Значит и сама модель для этой задачи не нужна. Где хранится состояние модели? В хранилище. Вот из него напрямую и запросим. Утрированный GET API контроллер: echo json_encode($pdo->query('select x1, x2 from y where z = ?')->fetch()).

это ты CQRS для себя открыл?

ну года два назад) но пост в первую очередь про то, что геттеры не нужны, а не про CQRS, хотя темы пересекаются

рид модель иногда бывает сложнее чем просто "вывести состояние"

да, поэтому у нас EventSorcing и туча проекций. но это бы вышло за рамки поста

просто последний абзац непонятный получился. т.е. как будто предлагается всё держать в полях базы данных...

понимаю, о чем ты, согласен, спасибо. ща мб поправлю

ооо, яб читнул про проекции и рид-модельки... 😋

как-нибудь напишу)