а есть кто-нибудь здесь из railsware?

ребята из Польши, которые

?

@davydovanton напомни, пожалуйста, а есть где-нибудь твоя преза с рубираша последней? Ты там перечислил разные способы вызвать сервисы: Foo.call(…), Foo.new.call(…), Foo.new(…).call и т.п.

Хочу список посмотреть. Чтоб протестить каждый — сколько памяти жрет, что быстрее (есть ли вообще разница?).

У меня-то мнение по поводу конкретных подходов есть, но хочется добавить туда каких-нибудь цифр

На ютубе есть, на канале РР

❤️

мне кажется,  не совсем логично foo.new.call(...) сравнивать с foo.new(...).call (допустим),
т.к. foo.new.call(..) ты можешь потом коллить сразными аттрибутами, а foo.new(..) в принципе один раз аттрибуты заинстанцирует и по памяти типа дешевле, но ты одну и туже операцию вызываешь многократно, и тут другие уже проблемы и вещи в принципе происходят (разное поведение в принципе И то, как ты это будешь использовать 🙂 )

а foo.call(...) в реализация может быть разной от случая к случаю (как функциональный объект, который неявно инстанцируется в call, или как модуль без состояния - просто module foo.call(...) без инстанцирования (типа один глобальный инстанс сервисника))

@morozzzko если прям вот эти все кейсы разберешь - было бы оч круто потом твои размышления и мысли послушать 🙂

Да, вот именно все эти кейсы хочу посмотреть и понять их цену и применимость

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

+ насчет расшарить мысли

Ванную, что никакой разницы не будет.

В памяти будет разница между тремя вариантами:

1. инстанциируешь объект и переиспользуешь между запросами
2. на каждый запрос спаунишь по объекту и выкидываешь
3. не инстанциируешь объектов

Ну и в производительности эти 3 варианта тоже по-разному будут, по идеи.

Но есть ещё идеологии и прагматизм — что-то делать некорректно потому что есть какие-то убеждения. Какие-то штуки делать удобно потому что можно сделать ХХХ

Вот эти различия — ценные

Хочу навсегда закрыть для себя вопрос с этими штуками. Иметь точку для разговоров «вот решение, вот последствия, договорились юзать? ок, пошли дальше». а то слишком много времени на такие штуки можно потратить

Все эти накладные расходы -- обычно копейки по сравнению с тяжестью бизнес-логики.

❤️

а вот споров вокруг них — до жопы. хочется их закрыть)

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

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

… сказал я в чате в рабочее время

но спасибо за идеи и мнения ❤️

Как по мне, это вопрос кодстайла, который должен быть согласован на уровне команды/проекта. Принципиального отличия между всеми этими способами нет.