Constructeurs et factories
Statut documentaire : architecture — voir Maturité et preuves.
Les constructeurs sont représentés séparément des méthodes ordinaires dans le modèle de publication ABI. Leur identité canonique est dérivée du type Runtime déclarant et des types de paramètres du constructeur ; la signature logique source d'un constructeur n'a pas de type de retour.
À la frontière ABI, une construction réussie retourne une référence opaque vers un objet Runtime. La couche .NET générée transforme cette référence en wrapper managé du type approprié.
construction managée
|
v
MethodId constructeur
|
v
référence objet Runtime
|
v
objet managé généré
Modèle de programmation public
Les API générées doivent exposer la construction sous une forme naturelle pour le langage, par exemple un constructeur ou une factory nommée selon le modèle de publication :
var session = new Session(options);
ou :
var session = Session.Create(options);
L'écriture exacte générée dépend du package et de la release. La documentation applicative doit suivre le SDK généré plutôt qu'invoquer manuellement les IDs de constructeur.
Surcharges de constructeur
Les surcharges sont distinguées par leurs types de paramètres. Le générateur de publication calcule les identités stables des constructeurs avant d'émettre le binding cible ; le name mangling du langage cible ne devient donc pas le contrat Runtime.
Valeurs par défaut et arguments optionnels
Les métadonnées de documentation peuvent porter des valeurs par défaut normalisées, et les générateurs cibles peuvent utiliser les defaults publiés lorsqu'ils sont représentables de manière sûre dans le langage cible.
Un binding ne doit pas inventer un default managé qui modifierait la sémantique Runtime. Lorsqu'une valeur par défaut ne peut pas être représentée fidèlement, l'appel généré doit demander l'argument explicitement ou exposer une surcharge générée dont le comportement est défini par le contrat de publication.
Ownership après construction
Un objet Runtime nouvellement construit possède une durée de vie indépendante des buffers temporaires utilisés pour les arguments de l'appel. Le wrapper généré porte la référence Runtime et la libère ensuite selon le contrat de durée de vie du binding.