Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decouple C++ Implementations from Python Bindings #47

Open
wgledbe opened this issue Mar 13, 2024 · 2 comments · May be fixed by #51
Open

Decouple C++ Implementations from Python Bindings #47

wgledbe opened this issue Mar 13, 2024 · 2 comments · May be fixed by #51
Assignees

Comments

@wgledbe
Copy link

wgledbe commented Mar 13, 2024

It would be unbelievably nice to use the core objects in other projects without being married to the Python bindings.

A potential refactor could look something like:

// Current
template<class Stuff>
struct Thing {
  // Blah...

  static void Build(py::module& m, const char* name) {
    auto obj = py::class_<Thing<Stuff>>(m, name);

    // more stuff

    Base::DenseBaseBuild(obj);
};

static void BuildThings(py::module& m) {
  Thing<Wow>::Build(m, "ThingWow");
  Thing<Fake>::Build(m, "ThingFake");
}

becomes

// Proposed
#include "Thing.h"
#include "BuildDenseBase.h"

template<class Stuff>
static void BuildThing(py::module& m, const char* name) {
  auto obj = py::class_<Thing<Stuff>>(m, name);

  // You already know

  BuildDenseBase<Thing<Stuff>>(obj);
}

static void BuildThings(py::module& m) {
  BuildThing<Wow>(m, "ThingWow");
  BuildThing<Fake>(m, "ThingFake");
}

This way, you'd have a totally separate folder (I like calling it bind) that only contains a bunch of these BuildWhatever functions. The core implementations wouldn't know about the bindings at all.
Really just flipping it all inside-out.

@wgledbe
Copy link
Author

wgledbe commented Mar 14, 2024

Proposed directory structure:

|-- repo root
    `-- asset
        |-- bind
        |-- include
        |   `-- ASSET
        |-- examples
        `-- src

@wgledbe
Copy link
Author

wgledbe commented Mar 16, 2024

Completed refactor of Solvers, Utils, and VectorFunctions.
Did not touch OptimalControl or anything that depends on it.

@wgledbetter wgledbetter linked a pull request Apr 6, 2024 that will close this issue
@wgledbetter wgledbetter self-assigned this Apr 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants