более того, ты так или иначе контроилруешь типы когда данные внутрь объекта попадают

например - через конструктор

а наружу их зачем выпускать?

а еще есть проперти без сеттеров

вот дата классы бы...

А что под дата-классами имеется ввиду?

А что под дата-классами имеется ввиду?

а как в котлине

и как в java9 походу будет

а еще есть проперти без сеттеров

публичные называются)

А что выпускать? Проперти? Они же не RO

вот тут выше скинули ссылку про primitive obsession.

id например

еще можно почитать про anemic model

А что выпускать? Проперти? Они же не RO

приведи пример ситуации когда тебе нужны геттеры и сеттеры, что-нибудь небольшое

операция какая-нибудь

Сходу хотел про uuid загнуть, но это немного не то

Вот так всегда, когда дело доходит до примеров, все становится печально

1. дженерики 2. тайпхинтинг для пропертей 3. тайп элиасы 4. пайп оператор 5. JIT

а потом перейти просто на котлин) там 1.2 релизнулся пару дней назад

Давай так, у нас есть объект, которым мы обмениваемся с какой-нибудь системой. В него нужно что-то записывать, а потом считывать. Пусть это будет пакет, который хранит id, body и еще что-нибудь

наверное надо добавить больше инфы о том какое у него поведение иначе это массив)

да че там горевать по yii, если можно сегодня поставить вменяемый контейнер и собрать любой фреймворк на любой вкус

За 1 день собрал то что мне нужно, ди, консоль, пср7, и тд

За 1 день собрал то что мне нужно, ди, консоль, пср7, и тд

О чем речь. В симфони просто хорошие компоненты + отличная синергия между ними.

а потом перейти просто на котлин) там 1.2 релизнулся пару дней назад

да я все думаю

Давай так, у нас есть объект, которым мы обмениваемся с какой-нибудь системой. В него нужно что-то записывать, а потом считывать. Пусть это будет пакет, который хранит id, body и еще что-нибудь

если это объект которым мы обмениваемся - он должен быть имутабельным (во всяком случае мы не должны его в процессе менять). Так что тут сойдут и публичные свойства. И это идеальный кейс для дата классов (которых нет в php)

О чем речь. В симфони просто хорошие компоненты + отличная синергия между ними.

В симфони куча косяков, один из которых их любовь в yml)

Давай так, у нас есть объект, которым мы обмениваемся с какой-нибудь системой. В него нужно что-то записывать, а потом считывать. Пусть это будет пакет, который хранит id, body и еще что-нибудь

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

если это объект которым мы обмениваемся - он должен быть имутабельным (во всяком случае мы не должны его в процессе менять). Так что тут сойдут и публичные свойства. И это идеальный кейс для дата классов (которых нет в php)

А как мы обеспечим имутабельность с публичными свойствами?

В симфони куча косяков, один из которых их любовь в yml)

Ну вот добавили php dsl для контейнера и роутинга, жить можно :)

А как мы обеспечим имутабельность с публичными свойствами?

на данный момент - увы никак)

можно поставить в phpdoc @readonly и натравить статический анализатор

https://github.com/phpstan/phpstan/blob/master/tests/PHPStan/Rules/Properties/data/writing-to-read-only-properties.php

Ну вот добавили php dsl для контейнера и роутинга, жить можно :)

Можно линк?

можно поставить в phpdoc @readonly и натравить статический анализатор

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

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

не, в этом задаче нет публичных свойств)

почему у людей сразу "если нет геттера - значит есть публичные свойства"

Можно линк?

https://github.com/symfony/symfony/pull/24180 https://github.com/symfony/symfony/pull/23834

Действительно, если можно просто __toString

так, про публичные в иммутабельном ты же сам написал)

https://github.com/symfony/symfony/pull/24180 https://github.com/symfony/symfony/pull/23834

Спасибо, в доке не видел, интересно почему по дефолту юмл

Действительно, если можно просто __toString

откуда у тебя взялся tostring - если для тебя важно только как сущность в шаблон запихнуть - ну ладно)

я предложил тебе задачку

попробуй решить ее без геттеров и сеттеров

тебе тут не нужен UI

нет базы данных

только php

А что разрешить-то?

Спасибо, в доке не видел, интересно почему по дефолту юмл

видно просто еще не вся конфигурация готова. Есть же просто конфиги

Ну т.е. какой апи должен быть?

А что разрешить-то?

у тебя есть класс User, в котором надо сделать возможность смены пароля. Для смены надо предоставить старый, и если он не ок - кинуть исключение

Ну т.е. какой апи должен быть?

вот а как ты до этого подобное делал?

у тебя вот был setPassword и getPassword

потом какой-нибудь UserManager

у тебя есть класс User, в котором надо сделать возможность смены пароля. Для смены надо предоставить старый, и если он не ок - кинуть исключение

Я тупой или просто ->changePassword($new, $old, $encryptor)

Я тупой или просто ->changePassword($new, $old, $encryptor)

ты все правильно понял)

Я тупой или просто ->changePassword($new, $old, $encryptor)

Я тоже об этом подумал

добавляем новое требование - запрещено юзать пароль который ты уже юзал (например проверять последние 10 паролей)

тебе надо для этого геттеры и сеттеры при таком подходе?

короч ложить поведение рядом с данными. Ну то есть ООП делать

Держать стек внутри и чекать?

Держать стек внутри и чекать?

тип того)

геттеры для UI в отсутствии альтернатив (view model) - ну тут уж ничего не поделать. Но это вообще как по мне смешивание ответственности

обработка и вывод данных

Если подумать, то у меня геттеры в основном для шаблонов. Меня больше беспокоит как быть с жирными конструкторами. Скорее из-за них начинаешь городить сеттеры

жирные конструкторы - маленькая проблема. Ну и есть билдеры

что бы туда сеттеры вынести

есть DTO

ERROR: S client not available

много чего есть

надо только захотеть

В каком-то яп в момент создания объекта создаются виртуальные сеттеры из параметров, которые указаны в конструкторе. После создание объекта, сеттеры закрываются

Если нужно обработать данные из этих сеттеров, то на них нужно просто подписаться

https://github.com/symfony/symfony/projects/6#card-4422613 интересно

Судя по всему yml будут вырезать

Ну точней максимально вырезать

про анемичное... а если у меня есть коробка в которой много предметов разной стоимости, и нужно чтоб выпал один из них - выигрыш, а шансы на предметы в коробке считаются от их стоимости. делаем $box->getDrop() а что делать когда шансы вдруг станут обсчитываться сторонним сервисом через api? можно не выносить это в отдельный сервис? потом появятся разные другие коробки у которых шансы будут обсчитываться еще парой разных способов

про анемичное... а если у меня есть коробка в которой много предметов разной стоимости, и нужно чтоб выпал один из них - выигрыш, а шансы на предметы в коробке считаются от их стоимости. делаем $box->getDrop() а что делать когда шансы вдруг станут обсчитываться сторонним сервисом через api? можно не выносить это в отдельный сервис? потом появятся разные другие коробки у которых шансы будут обсчитываться еще парой разных способов

предметны не могут посчитать свои шансы.

а могут и посчитать)

коробка может - предметы в ней

коробке в целом пофиг что за предметы - так?

это считай просто коллекция

ей важна только стоимость что бы построить распределение, так?

да пофиг

не, когда пофиг это менеджеры и анемичные модели)

ну хорошо следующий шаг - не пофиг, коробке важно что у нас в наличии есть, а это лежит где то в другом апи (остатки)

ну хорошо следующий шаг - не пофиг, коробке важно что у нас в наличии есть, а это лежит где то в другом апи (остатки)

почему ей не пофиг что у нее есть?)

короч опиши задачу нормально

ну предметы в ней - для витрины чтобы показать

а реально доставить можем только то что в наличии на складе

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

но показываем все - и то чего сейчас у нас нет

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

но показываем все - и то чего сейчас у нас нет

и в лотерее учавствует то чего нет?)

и в лотерее учавствует то чего нет?)

да, что то дорогое чего в наличии изначально было мало - привлекает, но быстро кончается на складе. дорогое мы всеравно показываем до лотереи а выдаём что осталось

потом оно может быть докуплено нами и тоже будет выпадать

еще пара вопросов которые я бы задал составителю требований: - что значит "показываем до лотереи"? Что-то типа рассылки? - Что будет если нам выпал товар, которого 1 единица на складе, и пока мы его выбирали лотереей кто-то его уже купил? На каком этапе должна происхоидть резервация товаров? Система резервации товаров наша или внешняя?

> - что значит "показываем до лотереи"? Что-то типа рассылки? показываем на странице коробки - ее содержимое, все что может выпасть и могло бы, если бы было в наличии, пользователь об остатках и наличии не знает. запускает лотерею - получает выигрыш > Что будет если нам выпал товар, которого 1 единица на складе, и пока мы его выбирали лотереей кто-то его уже купил? На каком этапе должна происхоидть резервация товаров? Система резервации товаров наша или внешняя? резервации нет, если так уж случилось что предмет в наличии 1 а выпал 5 игрокам то получает тот кто первый нажмет - ЗАБРАТЬ, остальные увидят статус - доставка, когда предмет докупят и он появится - будет переотправка и пользователь его получит. то есть подождать свой выигрыш если он кончился - норм, но мы стараемся избежать этого

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

Дока у симфони меняется прям налету )

ranbox напоминает