C.5.2 Obiettivi per un nuovo meccanismo

Alcuni obiettivi per la nuova API sono:

• L’API dovrebbe essere indipendente dalla struttura interna di gawk. Le modifiche alla struttura interna di gawk dovrebbero essere irrilevanti per chi scrive una funzione di estensione.
• L’API dovrebbe consentire una compatibilità binaria [ossia a livello di codice eseguibile, e non solo a livello di codice sorgente] tra diverse versioni di gawk, se la stessa API rimane invariata.
• L’API dovrebbe consentire che le estensioni scritte in C o C++ abbiano all’incirca la stessa “struttura”, per il codice awk, di quella che hanno le funzioni di awk. Questo vuol dire che le estensioni dovrebbero avere:
  • - La capacità di accedere ai parametri delle funzioni.
  • - La capacità di trasformare un parametro indefinito in un vettore (chiamata per riferimento [by reference]).
  • - La capacità di creare, leggere e aggiornare variabili globali.
  • - Un accesso facile a tutti gli elementi di un vettore simultaneamente (“appiattimento del vettore”) in modo da poter visitare tutti gli elementi del vettore in una maniera semplice per un programma scritto in C.
  • - La capacità di creare vettori (compresi i veri "vettori di vettori" di gawk).

Alcuni ulteriori obiettivi rilevanti sono:

• L’API dovrebbe usare solo funzionalità disponibili nella specifica ISO C 90, in modo da consentire estensioni scritte con una vasta gamma di compilatori C e C++. L’intestazione dovrebbe includere le appropriate direttive ‘#ifdef __cplusplus’ e ‘extern "C"’, in modo da poter utilizzare un compilatore C++. (Se si usa C++, il sistema operativo in uso dev’essere in grado di invocare dei costruttori e dei distruttori, poiché gawk è un programma scritto in C. Al momento in cui queste note sono scritte, la cosa non è stata verificata).
• Il meccanismo API non dovrebbe aver bisogno di accedere ai simboli di gawk¹²⁶ da parte del linker statico, usato in fase di compilazione, o di quello dinamico, in modo da rendere possibile la creazione di estensioni che funzionino anche in ambiente MS-Windows.

In fase di sviluppo, è apparso evidente che dovevano essere disponibili alle estensioni anche altre funzionalità, che sono state successivamente implementate:

• Le estensioni dovrebbero essere in grado di agganciarsi al meccanismo di ridirezione dell’I/O di gawk. In particolare, gli sviluppatori di xgawk hanno programmato un cosiddetto “gancio aperto” (open hook) per gestire autonomamente la lettura dei record. In fase di sviluppo, questo meccanismo è stato generalizzato, per consentire alle estensioni di agganciarsi sia all’elaborazione dell’input, che a quella dell’output, nonché all’I/O bidirezionale.
• Un’estensione dovrebbe poter rendere disponibile una funzione di “call back” (richiamo) per effettuare operazioni di pulizia all’uscita di gawk.
• Un’estensione dovrebbe poter rendere disponibile una stringa di versione così che l’opzione --version di gawk possa informare anche sulle versioni delle estensioni.

Il vincolo di evitare di accedere ai simboli di gawk può parere a prima vista piuttosto difficile da rispettare.

Un tipo di architettura, apparentemente usato da Perl e Ruby e forse da altri programmi, potrebbe consistere nel mettere il codice principale di gawk in una libreria, limitando il programma di utilità gawk a una piccola funzione main() in C che richiamerebbe dinamicamente la libreria.

Questo inverte i ruoli del programma principale e della sua estensione, e complica sia la compilazione che l’installazione, trasformando la semplice copia del programma eseguibile gawk da un sistema all’altro (o da una posizione all’altra all’interno dello stesso sistema) in un’operazione ad alto rischio.

Pat Rankin ha suggerito la soluzione che è stata adottata. Vedi la sezione Una panoramica sul funzionamento ad alto livello, per maggiori dettagli.