Implicit function arguments в Rust

а просто не писать

mut

а просто не писать

Куда не писать? Напиши подробнее, что именно ты имеешь ввиду.

Мне кажется, что конфиг имеет смысл только в районе функции main. А в более глубокие функции, значения из конфига передаются параметрами. Как-то странно, если у тебя через всё приложение просвистывает конфиг

А в более глубокие функции, значения из конфига передаются параметрами.

Да, можно и так, но это больше кода и, потенциально, больше проблем в будущем с его переписыванием, если где-то что-то понадобилось. Особенно если какое-то значение понадобится в функции, которая вызывается не напрямую из main, а где-то на втором-третьем уровне.

Неплохо было бы написать, что такое «ReaderT». Обычная структура с const не подойдет?

что такое «ReaderT».

Это монадический трансформер. Если проще, это такая штука, добавляющая к каждой функции, которая с ней объявлена, лишний невидимый за счёт каррирования аргумент, доступ к которому можно получить через специальный метод.

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

Тут есть пример кода: http://blog.ssanj.net/posts/2014-09-23-A-Simple-Reader-Monad-Example.html

Обычная структура с const не подойдет?

Тут вопрос в том как структуру передавать дальше по стеку вызовов.

Аналог ReaderT в Rust

&T

Неужели нужно городить глобальные переменные либо руками каждой фукнции писать лишний аргумент?

Второе, только он не «лишний»: https://github.com/rust-lang/cargo/blob/master/src/bin/cargo.rs

это такая штука, добавляющая к каждой функции, которая с ней объявлена, лишний невидимый за счёт каррирования аргумент, доступ к которому можно получить через специальный метод.

Еще немного и может им удастся изобрести инкапсуляцию и ООП

Я в хаскеле 0, но в rust переменная может попасть в функцию только через аргумент или из глобального пространства.

Лучший вариант - аргумент, ибо static/const в rust обязан быть thread-safe, из-за чего больше писанины.

Еще немного и может им удастся изобрести инкапсуляцию и ООП

А вот и свидетели ООП подтянулись.

Ну как раз задача ТС через наследование очень хорошо решается.

Ну как раз задача ТС через наследование очень хорошо решается.

Через наследование она не решается.

Если проще, это такая штука, добавляющая к каждой функции, которая с ней объявлена, лишний невидимый за счёт каррирования аргумент, доступ к которому можно получить через специальный метод.

Чем не наследование?

Что ты наследовать в чистой функции собрался?

Ну как раз задача ТС через наследование очень хорошо решается.

Эм... А как ты уже установленные параметры-то собрался наследовать?

Про чистую функцию речи и не было.

Не распарсил.

Про чистую функцию речи и не было.

А про объекты и прочий шлаг речь была?

Правильно я понимаю, что ReaderT это чтобы писать в стиле объектного Си: method(opaque_struct, params...), но только «замкнуть» opaque_struct, чтоб не писать ее каждый раз?

То-есть типичное страдание по некоей целостной сущности со стейтом и поведением. В rust для этого есть трейты и self для доступа к стейту

Ну как сделать так, шоп у нас был один экземпляр Config, в котором выставлены нужные значения, а все потомки класса Config имеют к ним доступ?

А какие проблемы?

ReaderT это чтобы писать в стиле объектного Си: method(opaque_struct, params...), но только «замкнуть» opaque_struct, чтоб не писать ее каждый раз?

Примерно. Только этот самый struct не обязательно opaque, и он будет передаваться неявно вниз по стеку вызовов.

В rust для этого есть трейты и self для доступа к стейту

Ты мне сейчас предлагаешь всю логику, зависащую от конфига, писать в impl Config {} штоле? Совсем наркоман?

TL;DR я хочу передавать конфиг вниз по стеку, но не хочу писать руками его передачу во все подряд функции. Так понятнее?

А какие проблемы?

Ну как тебе сказать... В том же C++ наследование определено для классов и структур. А не для экземпляров классов и структур :)

С точки зрения архитектуры есть такие варианты: 1. Глобальная переменная (плохо для тестирования), может быть плохо для многопоточности. 2. Threadlocal переменная. Может быть плохо для асинхронщины. 3. Прокидывать параметром/полем. Ну это скучно, но просто и работает. 4. Dependency Injection. Не знаю, как у раста с этим. 5. Implicit параметры. Разновидность 3 варианта, но прокидывается автоматически. Вроде у раста такого нет.

Я бы выбрал вариант 3 или 4.

Совсем наркоман?

Сгруппировать функции по сущностям. Сущность создавать entity::new(my_config). А внутри функций обращаться к конфигу через self

Хотя я бы так не делал, да. Херня получается. Лучше передавать в new только то, что ему действительно нужно

5. Implicit параметры. Разновидность 3 варианта, но прокидывается автоматически. Вроде у раста такого нет.

Я хочу примерно вот это, да.

Сущность создавать entity::new(my_config). А внутри функций обращаться к конфигу через self.

Т.е. ты предлагаешь по всюду раскидать копии конфига. Спасибо, но это немного не то. Проще тогда лишним параметром передавать.

Я в курсе. Я и предлагал наследоваться от Config у нужного класса. Тогда получилась бы «такая штука, добавляющая к каждой функции, которая с ней объявлена, лишний невидимый аргумент, доступ к которому можно получить через специальный метод».

Это глобальная переменная в жаба стиле же, нет?

Я в курсе. Я и предлагал наследоваться от Config у нужного класса. Тогда получилась бы «такая штука, добавляющая к каждой функции, которая с ней объявлена, лишний невидимый аргумент, доступ к которому можно получить через специальный метод».

А какой смысл в этом, если там дефолтный для класса параметр?

но не хочу писать руками его передачу во все подряд функции

Можно функцию в макрос обернуть, но это извращение уже.

Почему дефолтный? Он может быть синглтоном.

Почему дефолтный? Он может быть синглтоном.

Ну то есть мы опять вернулись к глобальной переменной.

Смотря какой. Тут мы можем гарантировать потокобезопасность, ленивую инициализацию и константность.

ты предлагаешь по всюду раскидать копии конфига

Хуже. Я предлагаю вычленить из конфига нужное и передавать только это в конструктор. Вдруг придет в голову переиспользовать часть кода? И придется тебе в другой програме воссоздавать ради одной функции всю структуру конфига

Хуже. Я предлагаю вычленить из конфига нужное и передавать только это в конструктор. Вдруг придет в голову переиспользовать часть кода? И придется тебе воссоздавать ради одной функции всю структуру конфига

А потом на третьем уровне вложенности в функции fuckYourMum мне потребуется получить параметр hugeAss. И чо мне делать?

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

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

Ну я к тому, что ООП тут слегка не при чем.

Есть код, который пишется для переиспользования, есть код, который пишется для решения конкретной задачи. Это разные подходы с разными требованиями. Не нужно везде пытаться писать код, который может быть когда-нибудь можно будет переиспользовать. Ты сразу вносишь все минусы ради возможных плюсов в будущем.

Ну и в твоём подходе правильно делать отдельный конфиг для твоего модуля (если это не 1-2 значения), делать адаптер для этого отдельного конфига от общего конфига и передавать уже этот отдельный конфиг. Т.е. куча работы и кода, который желательно помимо прочего тестировать и тд, ради эфемерного преимущества. Вот когда решишь переиспользовать, тогда и сделаешь рефакторинг.

Инкапсуляция есть, наследование есть. Что нужно, чтобы ООП стало причем?

Инкапсуляция есть, наследование есть. Что нужно, чтобы ООП стало причем?

Они тут есть по одной причине — в жабе нет глобальных переменных. Если бы они там были, то все это наследование стало бы слегка не нужным.

Доступ к глобальной переменной ограничить нельзя. В моём примере он ограничен - только для наследников класса. Это такая же глобальная переменная, как и ReaderT из оп поста.

есть код, который пишется для решения конкретной задачи

Тот самый, который вблизи main. И его как правило не так уж и много. Хотя, я проектов больше 20к строк не писал. Так что слова мои ничего не стоят

Это такая же глобальная переменная, как и ReaderT из оп поста.

Что ты несёшь, поехавший? ReaderT позволяет неявно передавать read-only значение, которое можно подменить без жопной боли в любом месте, а не даёт доступ к глобальному изменяемому массиву.

Доступ к глобальной переменной ограничить нельзя.

Кто сказал модули? Хотя ладно, даже в C это можно через #include'ы сделать.

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

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

ОК, согласен.

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

Это сделает его наследником, о чём я и говорил. Сравнение с ReaderT неудачное, признаю. Для неявной передачи параметров в ООП лучше просто использовать поля конкретного объекта. Но проблема описанная в вашем изначальном посте:

Ну как сделать так, шоп у нас был один экземпляр Config, в котором выставлены нужные значения, а все потомки класса Config имеют к ним доступ?

таки решена.

Возможно я плохо сформулировал вопрос, да.

Ну как тебе сказать... В том же C++ наследование определено для классов и структур.

В C++ решение могло бы выглядеть как-то вот так:

#include <utility>

struct Config {
	int a_;
	int b_;
};

class Config_holder {
	const Config cfg_;
public :
	Config_holder(Config cfg) : cfg_(std::move(cfg)) {}

	const Config & config() const { return cfg_; }
};

class App : public Config_holder {
	int c_;
public :
	App(Config cfg, int c) : Config_holder(std::move(cfg)), c_(c) {}

	int f() {
		return c_ + config().a_;
	}
};

class Another_app : public Config_holder {
	int d_;
public :
	Another_app(Config cfg, int d) : Config_holder(std::move(cfg)), d_(d) {}

	int g() {
		return d_ + App{Config{config().a_ + 1, config().b_}, d_ - 3}.f();
	}
};

int main() {
	Another_app app{Config{3, 4}, 25};

	app.g();
}

В принципе, аналогично можно было бы сделать и в Rust-а, полагаю, только там вместо наследования от Config_holder в App и AnotherApp нужно было бы просто инкапсулировать экземпляр структуры Config внутри структур App и AnotherApp.