Introspection et réflexion à l'exécution

Un programme qui ne peut pas s'examiner lui-même est un programme qui ne peut pas s'adapter. Quand vous construisez un générateur de formulaires qui crée des champs de saisie à partir d'une définition d'entité, vous devez savoir quels champs l'entité possède à l'exécution. Quand vous construisez un sérialiseur qui convertit n'importe quelle valeur en JSON, vous devez inspecter le type et la structure de la valeur dynamiquement. Quand vous construisez un débogueur, vous devez afficher le contenu de n'importe quelle variable sans connaître son type à l'avance.

C'est l'introspection -- la capacité d'un programme à examiner ses propres types et structures à l'exécution. Lors des Sessions 178 à 181, nous avons construit le système d'introspection de FLIN : un ensemble de fonctions intégrées qui permettent au code d'inspecter les types, d'énumérer les champs, de vérifier les propriétés et de naviguer dans les structures dynamiquement. Le tout sans sacrifier la sécurité des types qui rend FLIN fiable.

Les fonctions principales

type_of : qu'est-ce que cette valeur ?

flintype_of(42)                // "int"
type_of(3.14)              // "float"
type_of("hello")           // "text"
type_of(true)              // "bool"
type_of([1, 2, 3])         // "list"
type_of({ a: 1 })          // "map"
type_of(none)              // "none"
type_of(user)              // "User" (nom du type entité)

fields_of : quels champs cette entité possède-t-elle ?

flinfields = fields_of(User)
// ["name", "email", "age", "role"]

// Fonctionne aussi sur les instances
fields = fields_of(user)
// ["name", "email", "age", "role"]

Accès dynamique aux champs

flin// Get dynamique
value = get_field(user, "name")
// "Juste"

// Set dynamique
set_field(user, "name", "Thales")

Cas d'utilisation : génération dynamique de formulaires

Le cas d'utilisation phare de l'introspection est la génération automatique de formulaires. Étant donné un type d'entité, générer un formulaire complet avec les types d'entrée appropriés pour chaque champ :

flinentity Product {
    name: text
    description: text
    price: float where > 0
    in_stock: bool = true
    category: text
}

fn render_entity_form(entity_type) {
    fields = fields_of(entity_type)
    types = field_types_of(entity_type)

    <Form submit={handle_submit()}>
        {for field in fields}
            <FormField label={field.title}>
                {if types[field] == "text"}
                    <Input value={form_data[field]}
                           placeholder="Enter {field}" />
                {else if types[field] == "int" or types[field] == "float"}
                    <Input type="number"
                           value={form_data[field]} />
                {else if types[field] == "bool"}
                    <Switch checked={form_data[field]}
                            label={field.title} />
                {/if}
            </FormField>
        {/for}
        <Button type="submit" variant="primary">Save</Button>
    </Form>
}

Cette fonction génère un formulaire pour n'importe quelle entité. Passez-lui User, et elle crée des entrées pour name, email, age et role. Passez-lui Product, et elle crée des entrées pour name, description, price, in_stock et category. Le formulaire s'adapte à la structure de l'entité à l'exécution.

La frontière : introspection, pas réflexion complète

FLIN fournit l'introspection (examiner les types et structures) mais pas la réflexion complète (modifier les types et structures à l'exécution). Vous pouvez lire les champs d'une entité mais vous ne pouvez pas ajouter de nouveaux champs à l'exécution. Vous pouvez vérifier le type d'une valeur mais vous ne pouvez pas le changer.

C'est une limitation délibérée. La réflexion complète -- comme en Java, C# et Ruby -- permet une métaprogrammation puissante mais aussi du code impossible à comprendre statiquement. Le compromis de FLIN : vous pouvez tout inspecter, mais vous ne pouvez modifier les valeurs qu'à travers les mécanismes normaux du langage. La forme des types est fixée à la compilation. Les valeurs des champs sont dynamiques à l'exécution.

Quinze fonctions pour une introspection complète

L'API d'introspection complète :

• type_of(value) -- nom du type en tant que chaîne
• is_text(value), is_int(value), is_float(value), is_bool(value), is_list(value), is_map(value), is_none(value), is_entity(value) -- prédicats de type
• fields_of(entity) -- liste des noms de champs
• field_types_of(entity) -- map des noms de champs vers les types
• has_field(entity, name) -- vérifier l'existence d'un champ
• get_field(entity, name) -- lecture dynamique de champ
• set_field(entity, name, value) -- écriture dynamique de champ
• type_name(value) -- raccourci pour le nom du type entité

Quinze fonctions qui permettent la génération dynamique de formulaires, la sérialisation générique, la journalisation de débogage et la transformation de données -- sans sacrifier la sécurité des types qui rend les programmes FLIN fiables.

Ceci est la partie 77 de la série "How We Built FLIN", documentant comment un CEO à Abidjan et un CTO IA ont construit l'introspection à l'exécution dans un langage de programmation typé statiquement.

Navigation de la série : - [76] Security Functions: Crypto, JWT, Argon2 - [77] Introspection and Reflection at Runtime (vous êtes ici) - [78] Reduce, Map, Filter: Higher-Order Functions - [79] Validation and Sanitization Functions