Перенос кода C с изменяемыми заимствованиями — ошибка во время выполнения (пример nappgui)

Это действительно довольно сложно смоделировать в Rust. Давайте проанализируем, что мы здесь имеем:

У нас есть два пакета, low и high, которые зависят друг от друга, создавая цикл. Поскольку пакет low не знает о high, они создают этот цикл со стиранием типов и циклами в структуре данных.

Rust не любит циклы. Действительно, нет. Циклы в структурах данных практически невозможно создавать и управлять ими, и этот тип циклов не является исключением. Вы пытались проявить смекалку и избежать цикла, используя дерево композиции вместо графика, но цикл неизбежен. Вы избежали цикла в данных, но создали цикл в потоке кода.

Итак, вся надежда потеряна?

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

Решение — инвертировать композицию.

Вы пытались сдержать LowLevelObject в HighLevelObject. С концептуальной точки зрения это имеет смысл: в конце концов, композиция (как и наследование) берет существующие типы и добавляет к ним функциональность, поэтому имеет смысл включать «меньшие» типы в «большие» типы, не так ли?

Да. Но иногда мир заставляет нас идти против логики.

Когда мы сохраняем LowLevelObject в HighLevelObject, мы должны хранить обратные вызовы в LowLevelObject. Мы не можем хранить их в HighLevelObject, так как тогда LowLevelObject не сможет их найти. Но обратным вызовам нужна ссылка на HighLevelObject, а LowLevelObject не может дать им этого сам по себе, а HighLevelObject не может помочь, потому что это нарушит правила псевдонимов.

Другими словами, обратные вызовы должны храниться в структуре верхнего уровня. Это потому, что им нужен доступ как к HighLevelObject (напрямую), так и к LowLevelObject (косвенно, через его методы). Единственный тип, который может предоставить им это, — это тип, который содержит и то, и другое. Но с другой стороны, обратные вызовы не могут храниться в HighLevelObject, поскольку LowLevelObject необходимо их вызывать. Очевидным решением этих требований является наличие LowLevelObject внутри HighLevelObject.

Вы спросите, не нарушит ли это инкапсуляцию? Этого не произойдет, потому что мы удалим тип HighLevelObject - через дженерики или динамическую отправку.

Вот как это будет выглядеть:

// crate `low`

pub struct LowLevelObject<T> {
    pub listener: T,
    callback1: fn(&mut Self),
    callback2: fn(&mut Self),

    example_low_level_data: String,
}

impl<T> LowLevelObject<T> {
    pub fn low_api1(&mut self) {
        // some functionality
        (self.callback1)(self);
        // more functionality
    }

    pub fn low_api2(&mut self) {
        // some functionality
        (self.callback2)(self);
        // more functionality
    }

    pub fn low_api3(&mut self) {
        // some functionality
        println!("`low_api3()` - {}", self.example_low_level_data);
    }

    pub fn create(listener: T, callback1: fn(&mut Self), callback2: fn(&mut Self)) -> Self {
        Self {
            listener,
            callback1,
            callback2,
            example_low_level_data: "this is low-level data".to_owned(),
        }
    }
}

// crate `high`

pub struct HighLevelState {
    example_high_level_data: String,
}

pub type HighLevelObject = LowLevelObject<HighLevelState>;

// Define them either as free functions or in extension traits, whatever makes you feel better.

fn on_callback1(hi: &mut HighLevelObject) {
    println!("`on_callback1()` - {}", hi.listener.example_high_level_data);
    hi.low_api3();
}

fn on_callback2(hi: &mut HighLevelObject) {
    println!("`on_callback2()` - {}", hi.listener.example_high_level_data);
    hi.low_api3();
}

pub fn high_create() -> HighLevelObject {
    LowLevelObject::create(
        HighLevelState {
            example_high_level_data: "this is high-level data".to_owned(),
        },
        on_callback1,
        on_callback2,
    )
}

И вот ваш исходный код:

//////////////////////////////////////////////////////////
// Platform specific OSAPP library crate
// e.g. osapp_win.rs

pub struct OSApp<App> {
    pub app: App,
    abnormal_termination: bool,
    with_run_loop: bool,
}

pub fn init_imp<App>(app: App, with_run_loop: bool) -> OSApp<App> {
    OSApp {
        app,
        abnormal_termination: false,
        with_run_loop,
    }
}

pub fn run<App>(app: &mut OSApp<App>, on_finish_launching: &mut dyn FnMut(&mut OSApp<App>)) {
    on_finish_launching(app);

    if app.with_run_loop {
        // Following line commented out to simplify
        // osgui::message_loop();
        i_terminate(app);
    }
}

fn i_terminate<App>(_app: &OSApp<App>) {
    // Calls more client callbacks
}

//////////////////////////////////////////////////////////
// OSAPP crate

use core::f64;
use std::{cell::RefCell, rc::Rc};

struct AppState {
    _lframe: f64,
    func_create: FnAppCreate,
}

type App = OSApp<AppState>;

pub trait ClientObject {}
type FnAppCreate = fn() -> Box<dyn ClientObject>;

pub fn osmain(lframe: f64, func_create: FnAppCreate) {
    let mut app = init_imp(
        AppState {
            _lframe: lframe,
            func_create: func_create,
        },
        true,
    );

    let mut on_finish_launch = |app: &mut App| i_OnFinishLaunching(app);

    /*osapp::*/
    run(&mut app, &mut on_finish_launch);
}

fn i_OnFinishLaunching(app: &App) {
    (app.app.func_create)();
}

//////////////////////////////////////////////////////////
// main.rs

struct Application {
    // widgets go here
}

impl ClientObject for Application {}

impl Application {
    fn create() -> Box<dyn ClientObject> {
        let mut app = Box::new(Application {
            // Create all the widgets here
        });

        app
    }
}

fn main() {
    /*osapp::*/
    osmain(0.0, Application::create);
}

Примечание: если вы хотите сохранить замыкания захвата в обратных вызовах, вы столкнетесь с некоторыми проблемами. Их можно исправить с помощью некоторых хитростей, но я не думаю, что они вам понадобятся, поскольку вы портируете библиотеку C, а в C нет замыканий :)