Using your generated SDK

Kibo turns your DSM model into code you work against every day: typed classes over the Viper runtime, produced by the kibo-template-viper pack. This chapter is that daily surface for the code kibo 2 and kibo-template-viper 2.0 generate — one page per language.

The principle is shared (the Dual Reality: the same value seen as a typed object and as a runtime Value), and so is the vocabulary — one module or namespace per DSM namespace, structures, enumerations, keys, containers, attachments grouped by the concept they are keyed on, function pools. The form follows each language:

  • Python — a package over the dsviper wheel. A generated object is a box around one Viper value, with Python’s protocols: keyword constructors, ==, hash, <, enum.Enum, dict- and list-like containers.

  • TypeScript — an ES module package over the @digitalsubstrate/dsviper Node binding: the same boxes, with equals / hashKey / compare, string-union enumerations and bigint for 64-bit integers.

  • C++ — C++17 value types (struct, enum class, STL containers) that cross to a Viper::Value through a generated codec. It is the base reference: the Python and TypeScript packages offer what it offers, with its restrictions.

Each page covers the same ground in the same order: what the package holds, structures and enumerations, what is shared and what is copied, containers, keys, attachments and the stores they read and write, the bridge to the runtime, errors, and pools.

Generating the code is kibo-project’s job, from a project’s kibo.toml; which features a project selects is described in Templated Features, and packaging in Python Wheels and npm Packages.