предположим мне нужен update, я вынужден буду делать все поля optional?

с create схемой то вопросов нет

предположим мне нужен update, я вынужден буду делать все поля optional?

Maybe

предположим мне нужен update, я вынужден буду делать все поля optional?

да, я так делаю

required().maybe

предположим мне нужен update, я вынужден буду делать все поля optional?

я делал 2 формобъекта на create и update

Anton разве required не обязывает наличие ключа в хеше?

ребят, кто что для форм обжектов юзает? свое решение или готовое что-то?

ActiveModel

Anton разве required не обязывает наличие ключа в хеше?

Обязывает

Но там он может быть заполнен или нет

а если я обновляю только 1 поле у модели? он же мне в эррорах высрет кучу говна

Не должен

ну я же проверял

высрет, надо optional

тут вариант только делать optional

для обновления

и required для создания

если возможен null, то с maybe

если возможен null, то с maybe

даже звучит страшно ?

еще можно сделать отдельно форму, а необходимые на все случаи жизни валидации - в модели.

Да, я попутал, maybe на nil значение

Вообще для простого CRUD хватит и ORM (допустим ActiveRecord или SequelModel) валидации

и еще вопросик, если в драй валидейшене юзаешь config.type_specs = true, значит нужно всем атрибутам прописывать тип?

тут вариант только делать optional

Ага, 2 формы

Вообще для простого CRUD хватит и ORM (допустим ActiveRecord или SequelModel) валидации

ну у меня 1 из +- 100 моделей на +-300 строк

это не простой круд

из них примерно 30-50 валидации

которых там не должно быть

тогда 2 формы на create/update. Можно сделать одну базовую, другую от нее унаследовав.

Ага, 2 формы

Антон, по config.type_specs = true, если его true делаешь, то обязательно нужно 2-м аргументом в required писать тип же, верно?

тогда 2 формы на create/update. Можно сделать одну базовую, другую от нее унаследовав.

наследование боль

наследование боль

не помню уже точно, но в dry-validation как-то это делал

это не нужно

лучше сделать 2 независимых формы

ну тебе виднее)

на create и update

@davydovanton @RomanPa спасибо за помощь

очень зависит от ситуации

это зависит не от ситуации

Антон, по config.type_specs = true, если его true делаешь, то обязательно нужно 2-м аргументом в required писать тип же, верно?

А хз, я и так всегда типы пишу

ок, спасибо

это зависит не от ситуации

ну дублировать код пользуясь dry-rb не должно быть нужно по идее=)

ну если все делать аля DONT REPEAT YOURSELF

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

если нравится мазахизм, то enjoy

есть еще принцип KISS, который по мне даже важней :)

да

это самый топорный и самый очевидный паттерн

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

я не говорю все, я говорю что встречаются кейсы где можно инхеритить схему. Например валидация сигнатуры, которая во всех формах одинаковая)

я не говорю все, я говорю что встречаются кейсы где можно инхеритить схему. Например валидация сигнатуры, которая во всех формах одинаковая)

для этого есть предикейты в драе

https://dry-rb.org/gems/dry-validation/custom-predicates/

да их тоже пользовал. Например для валидации биткоин-адресов

например валидация номера телефона, эмейла, даты и т.д.

ну да

ну так ты сам себе противоречишь ?

ну так ты сам себе противоречишь ?

нет, просто считаю что каджое решение хорошо в своей ситуации

где-то наследование, где-то композиция

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

это не взаимоисключающие понятия

Игорь, ну говори уже)

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

мой опыт не солидарен с твоим)

мой опыт не солидарен с твоим)

и это круто! есть чем поделиться

и это круто! есть чем поделиться

полностью согласен

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

можно вообще от ООП отказаться

можно

и временами очень даже хочется=)

state все-таки боль

ERROR: S client not available

ага, в функциональщине тоже круто

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

И типизацию обязательно добавить. Тоже хайп по ней!

можно вообще от ООП отказаться

наследование в ООП не то что бы необходимая фича

Были бы абстрактные классы в рубях

вот тогда бы зажили

Ну

Было бы больше смысла в наследовании

че ты под абстрактным классом понимаешь?

бля короче насчет скрещивания ООП с функциональщиной в руби тут подвезли

как в джаве

а че там?

абстрактные классы

а

ясно

в моем любимом flamegragh завезли явное отображение циклом GC

и получаются интересные инсайты

https://docs.oracle.com/javase/tutorial/java/IandI/abstract.html

как в джаве

как в С++ скорее, в жабе интерфейсы

http://joxi.net/xAeBpG6HpZ5Jkr.png

пикрил - срез работы апи-прокси

голубое слева - запрос апишки через typhoeus

а плоские одноуровневые куски - это как раз когда профайлер натыкался на интерпретатор в процессе сборки мусора

нихуя ты художник

их примерно 40%

то есть элементарная вообще задача

получил xml по http, распарсил его OX'ом, конвертнул на лету в хеш, это на 40% - сборка мусора

а теперь представьте что у вас функциональная иммутабельность и вам на каждый чих надо собирать новый объект

https://docs.oracle.com/javase/tutorial/java/IandI/abstract.html

в чем проблема то же самое в руби сделать?

точнее иначе

нахуй это нужно

method_missing driven development?