Chaîne de génération des bindings
Statut documentaire : reference — voir Maturité et preuves.
logiCells publie les surfaces appelables du Runtime à partir d'un même modèle sémantique de publication. L'ABI native générée, les SDK de langage et le contrat RPC sont des projections de ce modèle, et non des API indépendantes.
métadonnées Runtime publiées
|
v
modèle de publication
| | |
v v v
ABI native SDK C# SDK Python
|
v
bridge / dispatcher RPC
Modèle de publication
Le générateur inspecte les types, méthodes, propriétés, callbacks, constructeurs, directions de paramètres, valeurs par défaut et métadonnées de documentation publiés. Il calcule ensuite des identités d'invocation stables et les projections propres aux langages cibles.
La publication est sélective. Un type peut être une racine publique ou seulement un type référencé requis par une signature publique. Le manifeste ABI enregistre aussi si un type est publié ou seulement référencé.
Identité d'invocation stable
Chaque membre appelable généré reçoit un TypeId et un MethodId stables, dérivés des noms canoniques et des signatures. Les SDK générés et les requêtes RPC réutilisent ces identités.
Un même modèle objet généré peut ainsi appeler un adaptateur natif local ou un adaptateur RPC distant sans introduire un second système d'identification des méthodes.
Projections cibles
Les générateurs actuels contiennent des projections explicites pour :
- booléens et entiers 32 bits ;
- entiers 64 bits ;
- flottants simple et double précision ;
- chaînes UTF-8 ;
- références d'objets/interfaces sous forme de handles opaques ;
- tableaux avec conservation du type d'élément ;
- propriétés et propriétés callback ;
- constructeurs et méthodes ordinaires ;
- valeurs de paramètres par défaut et surcharges générées lorsque nécessaire.
La présence d'une projection dans un générateur ne prouve pas que tous les bridges d'exécution supportent le même type. Le support doit donc être décrit par couche : publication/génération, wrapper ABI natif, bridge d'exécution local et bridge RPC.
Conséquence pour les SDK
Un binding généré doit préserver la forme sémantique du Runtime plutôt que d'exposer pointeurs, identifiants de méthodes ou règles d'allocation au code applicatif. Ces détails restent dans l'infrastructure générée/runtime.
Pour .NET, le code applicatif doit donc voir des classes, interfaces, propriétés, méthodes, tableaux et chaînes générés, tandis que le binding gère les handles, l'UTF-8, les libérations et les descripteurs d'invocation.