Skip to content
Back to top
View this page

# Code Generation

Kibo generates application infrastructure from DSM definitions. The developer focuses on business logic while Kibo handles repetitive plumbing.

## Why Generate Code?

### The Amplification Effect

For every line of DSM, Kibo generates approximately 57 lines of C++ and Python:

Project | DSM Lines | Generated Lines | Ratio
--- | --- | --- | ---
Graph Editor (Pilot) | 273 | 15,592 | 57x
Raptor Editor (Industrial) | 2,003 | 126,182 | 63x

### What Gets Generated vs What You Write

Category | Who Writes It | Examples
--- | --- | ---
DSM definitions | Developer | `Graph.dsm`, `Pool_ModelGraph.dsm`
Infrastructure | Kibo | Serialization, persistence, accessors
Business logic | Developer | Domain rules, algorithms, UI

The generated infrastructure handles:

- Type-safe data structures

- Attachment accessors (get/set/keys via abstract interfaces)

- Database persistence layer

- Binary and JSON serialization

- Python bindings

- RPC marshalling

## The Double Reality

Kibo creates two coexisting realities that are bridged transparently:

### Developer Reality

What you see and code:

- Static C++ types with IDE support

- STL containers (`std::vector`, `std::map`)

- Compile-time type errors

- Idiomatic, readable code

    // Developer writes natural C++
    MyStruct data{"hello", {1, 2, 3}};
    data.items.push_back(42);

### Runtime Reality

What happens behind the scenes:

- Metadata-driven operations

- Reference semantics with `shared_ptr`

- Automatic serialization

- Python interoperability

- RPC without manual marshalling

    ┌─────────────────────────────────┐
    │  Developer Reality              │
    │  Static C++ types, Python types │
    │  MyStruct data{"hello", ...};   │
    └─────────────────────────────────┘
    ═══════════════════════════════════
    ┌─────────────────────────────────┐
    │  Runtime Reality                │
    │  Dynamic metadata, shared_ptr   │
    │  Serialization, RPC             │
    └─────────────────────────────────┘

The developer writes idiomatic C++ and never sees the runtime reality—Kibo generates the bridge code.

## Generated Layers

### 1. Data Layer

Generates type-safe business types:

- Concept keys (`VertexKey`, `EdgeKey`)

- Structures as C++ classes

- Enumerations

- Hash functions for containers

    // DSM input
    concept Vertex;
    struct Position { float x; float y; };

    // Generated output
    class VertexKey { ... };
    struct Position { float x; float y; };

### 2. Attachments Layer

Generates stateful accessors for attachments:

    // Generated accessor API
    auto topology = Attachments::Graph_Topology::get(attachmentGetting, graphKey);
    Attachments::Graph_Topology::set(attachmentMutating, graphKey, newTopology);
    Attachments::Graph_Topology::unionVertexKeys(attachmentMutating, graphKey, {key});

### 3. Database Layer

Generates persistence without writing SQL:

- SQLite backend for local storage

- Remote database client for RPC

- CRUD operations for all attachments

### 4. Serialization Layer

Generates two-way converters:

- Binary serialization (efficient, compact)

- JSON serialization (human-readable)

- C++ ↔ Viper Value bridge

### 5. Function Pool Layer

Generates function exposure:

- Marshalling between C++ and Viper

- Marshalling Python and Viper

- RPC server and client stubs

### 6. Python Package Layer

Generates a complete Python package:

    # Generated Python package
    import ge.data as ged
    import ge.attachments as gea

    # Use generated types
    vertex_key = ged.Graph_VertexKey.create()
    position = ged.Position()
    position.x = 10.0
    position.y = 20.0

    # Use generated accessors
    gea.graph_vertex_render2d_attributes_set(
        attachment_mutating, vertex_key, position
    )

## The Bridge Pattern

The Bridge connects your business logic to DSM-declared functions:

    ┌────────────────────────────────────────────┐
    │  DSM (Pool_ModelGraph.dsm)                 │
    │  mutable key<Vertex> newVertex(...)        │
    └─────────────────────┬──────────────────────┘
                          │ generates
    ┌─────────────────────▼──────────────────────┐
    │  Bridge.hpp (GENERATED - contract)         │
    │  VertexKey new_vertex(...);                │
    └─────────────────────┬──────────────────────┘
                          │ implements
    ┌─────────────────────▼──────────────────────┐
    │  Bridge.cpp (BUSINESS - hand-written)      │
    │  return Model::Vertex::add(...);           │
    └─────────────────────┬──────────────────────┘
                          │ exposes via
    ┌─────────────────────▼──────────────────────┐
    │  FunctionPools.cpp (GENERATED)             │
    │  Value ↔ C++ marshalling                   │
    └─────────────────────┬──────────────────────┘
              ┌───────────┴───────────┐
              ▼                       ▼
       Python Local            Remote RPC

### Example Workflow

1. DSM Declaration:

    attachment_function_pool ModelGraph {9bdcbb5b-76e9-426f-b8a6-a10ed2d949e6} {
        mutable key<Vertex> newVertex(key<Graph> graphKey, int64 value, Position position);
    };

2. Bridge Header (Generated):

    // GE_AttachmentFunctionPoolBridges.hpp - GENERATED by Kibo
    namespace GE::AttachmentFunctionPoolBridges {
    namespace ModelGraph {

    Graph::VertexKey new_vertex(std::shared_ptr<Viper::AttachmentMutating> const & attachmentMutating,
                                Graph::GraphKey const & graphKey,
                                std::int64_t value,
                                Graph::Position const & position);

    }
    }

3. Bridge Implementation (Business):

    // GE_AttachmentFunctionPoolBridges.cpp - HAND-WRITTEN
    Graph::VertexKey new_vertex(std::shared_ptr<Viper::AttachmentMutating> const & attachmentMutating,
                                Graph::GraphKey const & graphKey,
                                std::int64_t value,
                                Graph::Position const & position) {
        return Model::Vertex::add(attachmentMutating, graphKey, value, position,
                                  Model::Random::makeColor());
    }

4. Call from Python:

    # Automatically available in Python
    vertex_key = pool.new_vertex(commit, graph_key, 42, position)

## Workflow Summary

    ┌──────────────────┐     ┌──────────────────┐     ┌──────────────────┐
    │  Write DSM       │     │  Run Kibo        │     │  Write Business  │
    │  definitions     │ ──► │  code generator  │ ──► │  logic in        │
    │  (273 lines)     │     │                  │     │  Bridge.cpp      │
    └──────────────────┘     └──────────────────┘     └──────────────────┘
                                     │
                                     ▼
                        ┌───────────────────────────┐
                        │  Generated Infrastructure │
                        │  - Data types             │
                        │  - Serialization          │
                        │  - Persistence            │
                        │  - Python proxy           │
                        │  (15,592 lines)           │
                        └───────────────────────────┘

## Benefits

Benefit | Explanation
--- | ---
Less code to write | 57x amplification means 57x less code to maintain
Type safety | Generated code is type-safe, reducing runtime errors
Consistency | All serialization and persistence follows the same patterns
Multi-language | Same DSM generates C++ and Python code
Evolution | Change DSM, regenerate, and infrastructure updates automatically

## What’s Next

- Architecture - Application structure with generated code

- Toolchain: Kibo - Using the Kibo code generator