Binding generation pipeline
Documentation status: reference — see Maturity and evidence.
logiCells publishes callable Runtime surfaces from one semantic publication model. The generated native ABI, language SDKs, and RPC contract are projections of that model rather than unrelated APIs.
published Runtime metadata
|
v
publication model
| | |
v v v
native ABI C# SDK Python SDK
|
v
RPC bridge / dispatcher
Publication model
The generator inspects published types, methods, properties, callbacks, constructors, parameter directions, defaults, and documentation metadata. It then computes stable invocation identities and target-language projections.
Publication is selective. A type can be a published root or merely a referenced type required by a published signature. The generator also records whether a type is published or referenced-only in the ABI manifest.
Stable invocation identity
Every generated callable member is assigned a stable TypeId and MethodId derived from canonical names and signatures. Generated SDKs and RPC requests reuse these identities.
This lets a generated object model call either a local native adapter or a remote RPC adapter without inventing a second method identity scheme.
Target projections
The current generators contain explicit projections for:
- booleans and 32-bit integers;
- 64-bit integers;
- single- and double-precision floating point values;
- UTF-8 strings;
- object/interface references as opaque handles;
- arrays with retained element type information;
- properties and callback properties;
- constructors and ordinary methods;
- default parameter values and generated overloads where applicable.
The existence of a projection in a generator does not guarantee that every execution bridge supports the same kind. Support must therefore be described per layer: publication/generation, native ABI wrapper, local execution bridge, and RPC bridge.
Why this matters to SDK authors
A generated binding should preserve the semantic shape of the Runtime instead of exposing raw pointers, method IDs, or allocator rules to application code. Those low-level details remain inside generated/runtime infrastructure.
For .NET, this means application code should see generated classes, interfaces, properties, methods, arrays, and strings while the binding owns handle conversion, UTF-8 conversion, release calls, and invocation descriptors.