Э
У меня есть общий конфиг, и я хочу его обеднять по пути перехода через слои абстракции. Обрезать лишние поля
Какое-то динамическое программирование.
Size: a a a
2020 September 24
V
А, да, то что ты хочешь наверное лучше в паттерн билдер запихнуть
Э
У меня есть общий конфиг, и я хочу его обеднять по пути перехода через слои абстракции. Обрезать лишние поля
А тебе его надо собирать или разбирать?
f
А тебе его надо собирать или разбирать?
Разбирать. Сначала он большой, содержит в себе информацию для всей системы. Потом он проходит через дерево компонент, и более низкоуровневым компонентам нужно всё меньше информации
f
Ну я руками поля перекладываю, и норм
AS
Ну я руками поля перекладываю, и норм
а почему бы не составлять общий конфиг сразу из множества мелких конфигов для отдельных компонентов и явно требовать нужный конфиг в конструкторе компонента?
мы обычно так делаем
мы обычно так делаем
AS
переложить какое то поле можно и забыть
Э
Разбирать. Сначала он большой, содержит в себе информацию для всей системы. Потом он проходит через дерево компонент, и более низкоуровневым компонентам нужно всё меньше информации
Почему бы просто не выдавать ссылку на общий конфиг?
f
а почему бы не составлять общий конфиг сразу из множества мелких конфигов для отдельных компонентов и явно требовать нужный конфиг в конструкторе компонента?
мы обычно так делаем
мы обычно так делаем
Множество мелких конфигов в итоге собирается из нескольких полей основного конфига, а-ля
К тому же все эти три конфига живут в разных крейтах:
Server <- DhtAndVmUnion <- (DHT, VM)
Я конфиги держу в крейтах соответствующих компонент, и не хочется чтобы Serve зависел напрямую от DHT или VM, не его это дело :)
struct ServerConfig {
key_pair: Keypair,
base_dir: PathBuf,
envs: Vec<String>,
}
struct DHTConfig {
peer_id: PeerId, // = key_pair.public().to_peer_id
work_dir: PathBuf // = base_dir.join("something")
}
struct VMConfig {
envs: Vec<String>,
work_dir: PathBuf, // = base_dir.join("otherthing")
}К тому же все эти три конфига живут в разных крейтах:
Server <- DhtAndVmUnion <- (DHT, VM)
Я конфиги держу в крейтах соответствующих компонент, и не хочется чтобы Serve зависел напрямую от DHT или VM, не его это дело :)
f
Почему бы просто не выдавать ссылку на общий конфиг?
Две причины:
- Через некоторое время зависимость компонент от данных в конфиге становится сложной для понимания. Тут решение – ограничить кол-во данных
- Низкоуровневым модулям (DHT, VM) незачем знать про структуры высокоуровневых (Server)
- Через некоторое время зависимость компонент от данных в конфиге становится сложной для понимания. Тут решение – ограничить кол-во данных
- Низкоуровневым модулям (DHT, VM) незачем знать про структуры высокоуровневых (Server)
AS
Множество мелких конфигов в итоге собирается из нескольких полей основного конфига, а-ля
К тому же все эти три конфига живут в разных крейтах:
Server <- DhtAndVmUnion <- (DHT, VM)
Я конфиги держу в крейтах соответствующих компонент, и не хочется чтобы Serve зависел напрямую от DHT или VM, не его это дело :)
struct ServerConfig {
key_pair: Keypair,
base_dir: PathBuf,
envs: Vec<String>,
}
struct DHTConfig {
peer_id: PeerId, // = key_pair.public().to_peer_id
work_dir: PathBuf // = base_dir.join("something")
}
struct VMConfig {
envs: Vec<String>,
work_dir: PathBuf, // = base_dir.join("otherthing")
}К тому же все эти три конфига живут в разных крейтах:
Server <- DhtAndVmUnion <- (DHT, VM)
Я конфиги держу в крейтах соответствующих компонент, и не хочется чтобы Serve зависел напрямую от DHT или VM, не его это дело :)
мне кажется вы себе создаёте сложности на ровном месте, а потом героически их преодолеваете)
f
мне кажется вы себе создаёте сложности на ровном месте, а потом героически их преодолеваете)
А можно подробнее? :) Я буду только рад упроститься
AS
ну то есть ваш подход - это явный оверкил для просто передачи конфигурационных параметров)
DL
А почему не into из большоггг конфига в маленькие ?
f
А почему не into из большоггг конфига в маленькие ?
Ну в общем-то так и есть
AS
А можно подробнее? :) Я буду только рад упроститься
так он и не будет
Server (server config, который при инициализции дергает инициализацию union конфига) <- DhtAndVmUnion (requires union config (фактически обертка над dht и vm config, которая дёргает их конструкторы при инициализации) <- (DHT (requires dht config), VM (requires vm config))
Server (server config, который при инициализции дергает инициализацию union конфига) <- DhtAndVmUnion (requires union config (фактически обертка над dht и vm config, которая дёргает их конструкторы при инициализации) <- (DHT (requires dht config), VM (requires vm config))
AS
все общие параметры явно требуются нижележащими конфигами в конструкторе
в итоге получается очень простая и удобная схема, без ручного перекладывания полей, которое еще никак не контролируется языком
в итоге получается очень простая и удобная схема, без ручного перекладывания полей, которое еще никак не контролируется языком
f
Я чувствую недопонимание :)
f
Конфиги друг друга принимают в конструкторы, или наоборот предоставляют билдеры для низлежащих конфигов
f
Языком всё контролируется, тк поля-то нужно инициализировать, и аргументы передавать в конструктор, иначе не скомпилируется :)