Я познал силу декларативного кода когда давно писал чисто фронтенд. И когда ты описываешь виджет конфигом, декларативно, ключ-значение - это было большим шагом по сравнению с явным описанием всего. Такими же там были модели, которые ходили на сервер по единому протоколу. И вот они тоже все напрочь были декларативны. И всё было декларативно где это только было можно. Идеально же - разделение описания функциональности от явных команд для исполнения и прочей рантайм-логики. Возможно по этому мне больше по душе пришелся активрекорд. Но скорость - тож аргумент, да... Ну и наследование интереснее, динамическое задание всего без костылей и всё такое тоже имеет свои плюсы.

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

Так правила поведения - это мета, по которым ориентируется рантайм

твое хуже может быть настолько ничтожным что незаметно

что?

что значит поведение само себя определяет?

это как?

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

я не люблю explicit подход

собственно нелюбители рельсы как правило и есть нелюбители магии и implicit кода.

Не. Когда создаётся объект с передачей параметров — ему задаётся​ состояние. И при инициализации он не должен выполнять код, он просто устанавливает себе состояние, создаётся. Дальше вызываются у него методы, его поведение, которое использует его состояние. Это ООП. Мне кажется, ты путаешь, или смешиваешь.

Это тоже ООП, просто состояние декларируется на уровне класса. Причем это может быть базовое состояние, которые потом дополняется или даже переопределяется в зависимости от логики. Более того - в базовом виде это давно существует - константы! Просто сейчас в нашем веке можно методы вызывать, которые обрабатывают константу на уровне класса 1 раз, до создания экземпляра

has_many :stuff Это магия.

Вот, в конструкторе оно будет вызваться каждый раз при создании экземпляра, если вынести всё это на уровень класса - лишь 1 раз

когда я ему говорил как богически иметь has_many

да, он совал свой путон и говорил как это круто

С чего ты взял, что одно один раз будет вызываться? Тебе же мердж нужен дефолта. Он будет происходить каждую инициализацию в любом случае

Нет, либо мы о разном :)

да, он совал свой путон и говорил как это круто

Ну ты ему набил морду?)

там тупо они пишутся, типа такого: import AnotherModel from Orm class Model: posts = AnotherModel.many()

ну это explicit

мне питонист недавно тоже что то про ООП втирал

он еще аргументировал что питон понятнее для сишников

там тупо они пишутся, типа такого: import AnotherModel from Orm class Model: posts = AnotherModel.many()

но оно не будет так работать.

class Model posts = AnotherModel.many() end Model.posts

Всем привет! Вопрос для тех, кто использует rails + devise_token_auth и react + redux на фронте: есть ли какие-то более-менее универсальные npm-пакеты для упрощения аутентификации и хранения токенов (нашёл redux-auth, но он устарел), или же обычно пишут такое вручную под каждый проект?

спасибо за совет, пожалуй, так и поступлю

Всем привет! Вопрос для тех, кто использует rails + devise_token_auth и react + redux на фронте: есть ли какие-то более-менее универсальные npm-пакеты для упрощения аутентификации и хранения токенов (нашёл redux-auth, но он устарел), или же обычно пишут такое вручную под каждый проект?

такс, проблема оказалась в том, что при редиректе на рут, не меняется хедер, как можна заставить рельсу перезаписать head?