Il caso in cui un operatore a livello sorgente descrive effettivamente un'operazione che si svolgerà in qualche punto futuro, thunk l'operatore reale insieme ai suoi operandi.
Non so se questo ha un nome generico, o forse è un elemento di design di livello troppo basso per essere pensato come un "modello", ma comunque è un elemento che viene spesso visto in un numero di situazioni:
- Se ho capito bene (non un utente C ++ frequente), Boost :: Phoenix fa questo per rappresentare le sue operazioni lambda e pigro, ad es. overloading + per acquisire effettivamente gli argomenti insieme alla funzione reale + per il loro tipo
- I combinatori di parser in linguaggi funzionali (o qualcosa di simile a Spirit) sembrano operatori sui dati, ma in realtà costruiscono un parser che viene eseguito successivamente
- Altre EDSL (in lingue con overloading dell'operatore) sembrano fare molto questo, ad es. le librerie di programmazione reattiva funzionale tendono a costruire in modo invisibile le procedure che eseguiranno ciò che l'operazione sembra stia facendo in questo momento
- (Di nuovo, se ho capito bene) IO in Haskell costruisce un calcolo imperativo di componenti puri che viene poi "eseguito" dalla magia oscura nascosto nel runtime del linguaggio, mentre sembra che stia eseguendo solo le funzioni sul posto
- Ad un livello più semplice, Greenspunning un mini-Lisp incorporato in un programma C potrebbe essere considerato la stessa cosa: le S-espressioni possono essere costruite con chiamate a funzioni C, per essere eseguite più tardi (quest'ultima probabilmente sarebbe di solito considerato il caso antipattern), ti fa sembrare che stai passando "a lambda" a una funzione C, quando stai davvero passando i dati dell'interprete
Ovviamente non è un antipattern in tutti i casi, in quanto in alcuni di questi è l'unico modo di usare lo strumento in questione (farlo in C potrebbe far guadagnare un pestaggio). Non penso che sia "Greenspunning" o "utilizzando una EDSL" da solo, in quanto può essere più generico e ampiamente applicabile. Non penso che sia il pattern di Interpreter, anche se forse non l'ho capito correttamente: il calcolo viene costruito direttamente eseguendo il codice del linguaggio host (quindi esiste effettivamente in fase di compilazione, ma di solito non è un linguaggio di prima classe costrutto), anziché analizzare una stringa o altri dati caricati in runtime.
In tutti i casi, ciò che sembra accadere è che un'operazione sembra che stia facendo una cosa (non necessariamente in modo molto convincente, se è C e devi scrivere Aggiungi invece di sovraccaricare +, ma stessa idea), mentre in realtà impacchetta quell'azione per un consumo successivo. Qualcosa come un "costruttore di calcolo"? Ma non ho trovato quel termine in uso.
Non ho un problema pratico da risolvere qui; mi disturba solo che sembra esserci un elemento di design comune a cui non riesco a dare un nome.
(domanda originariamente pubblicata su StackOverflow, spostata a mano)