Мой предыдущий вопрос по этой теме был правильно определен как экземпляр проблемы XY.
Я пытаюсь создать ящик управления ресурсами длярешить, кто получит арендовать наводнение.Открытый интерфейс (в настоящее время) выглядит примерно так:
pub struct Bid<T> {
max_bid: TokenPerNanoSecond,
budget: Token,
data: T
}
/// Returns a vector of tuples of (T, time of rent end, tokens spent)
pub fn who_rents_the_flooble<'a, T>(
mut bids: Vec<&'a mut Bid<T>>
) -> Vec<(T, NanoSecond, Token)> {
let mut output = vec![];
let mut now = NanoSecond::from(0);
// while bids.len() > 0 {
// run a mini auction to work out who wins
// increment now by the duration
// append winner's data, now and amount spent to output
// subtract amount spent from winner's budget
// remove bids with no budget left
// }
output
}
Token
, NanoSecond
и TokenPerNanoSecond
являются новыми типами u64
с полностью определенными арифметическими отношениями;в основном они присутствуют только потому, что я плохо разбираюсь в алгебре и не хочу, чтобы из-за моих основных ошибок в алгебре и слияния семантически различных данных появлялись скрытые ошибки.
T
- это чисто непрозрачная вещь,Это void *
обратных вызовов C, которые позволяют вызывающему абоненту определить связь между тем, что вошло и что получилось.
Однако Vec<&'a mut Bid<T>>
на самом деле не делает то, что мне нужноделать.Чтобы реализовать «мини-аукцион», мне нужно переупорядочить Vec<&'a Bid<T>>
копию bids
, что требует владения ссылками и оставит меня немного застрявшим, когда мне в следующий раз понадобится изменить Bid
s.
Как должна выглядеть моя архитектура?
Если этой информации недостаточно, обратите внимание, что я пытаюсь повторно внедрить этот плохой код в Руст.