Estensioni native della lingua dello script: evitare conflitti di nome e ingombrare lo spazio dei nomi degli altri

Question

Estensioni native della lingua dello script: evitare conflitti di nome e ingombrare lo spazio dei nomi degli altri

#1 da (2 voti)

8

Ho sviluppato un piccolo linguaggio di scripting e ho appena iniziato a scrivere i primi binding della libreria nativa. Questa è praticamente la prima volta che scrivo un'estensione nativa a un linguaggio di script, quindi mi sono imbattuto in un problema concettuale.

Mi piacerebbe scrivere il codice della colla per le librerie popolari in modo che possano essere utilizzate da questo linguaggio, e grazie al design del motore che ho scritto, questo si ottiene usando un array di C struct s che descrive il nome della funzione visibile dalla macchina virtuale, insieme a un puntatore di funzione.

Quindi, un legame nativo è in realtà solo una variabile di array globale, e ora devo ovviamente dargli un nome (preferibilmente buono). In C, è idiota mettere le proprie funzioni in uno "spazio dei nomi" anteponendo un prefisso personalizzato ai nomi delle funzioni, come in myscript_parse_source() o myscript_run_bytecode() . Il nome personalizzato descriverà idealmente il nome della libreria di cui fa parte. Qui sorge la confusione.

Diciamo che sto scrivendo un'associazione per libcURL . In questo caso, sembra ragionevole chiamare la mia libreria di estensioni curl_myscript_binding , come questa:

MYSCRIPT_API const MyScriptExtFunc curl_myscript_lib[10];

Ma ora questo si scontra con lo spazio dei nomi curl . (Ho anche pensato di chiamarlo curlmyscript_lib ma sfortunatamente, libcURL non usa esclusivamente il prefisso curl_ - le API pubbliche contengono macro come CURLCODE_* e CURLOPT_* , quindi presumo che questo ingombrerebbe anche lo spazio dei nomi .)

Un'altra opzione sarebbe dichiararla come myscript_curl_lib , ma va bene solo finché sono l'unico che scrive vincoli (dato che so cosa sto facendo con il mio spazio dei nomi). Non appena gli altri contributori iniziano ad aggiungere i propri binding nativi, ora ingombrano lo spazio dei nomi myscript . (Ho fatto qualche ricerca, e sembra che ad esempio il collegamento Perl cURL segue questo schema Non sono sicuro di cosa dovrei pensare ...)

Quindi come suggerisci di nominare le mie variabili? Ci sono delle linee guida generali da seguire?

coding-standards naming-standards scripting

posta H2CO3 07.10.2013 - 19:47

fonte

1 risposta

Leggi altre domande sui tag coding-standards naming-standards scripting

Esiste un modo ragionevole per una classe TypeScript di derivare da una classe Dojo / Dijit? Iniezione della logica di elaborazione dati in classe

score 2 · Answer 1

Ben realisticamente, non è necessario contenere una serie globale di funzioni esportate solo per renderle visibili al tuo ambiente di runtime.

Una buona domanda da porsi è se il tuo ambiente di runtime salva il puntatore alla funzione e il nome ad esso associato?

La tua idea di utilizzare un array globale per esportare le funzioni ha senso solo se il tuo ambiente di runtime non salva quelle informazioni, ma presumo che tu debba salvarlo per l'ambiente di esecuzione della VM per eseguirlo correttamente.

Una funzione comune che viene aggiunta al linguaggio di scripting come la tua è l'idea di registrare le tue funzioni .

Essenzialmente, è necessario un supporto per memorizzare la funzione esportata ptr e il nome del puntatore della funzione esportata che verrà utilizzato nel codice dello script.

Conosco due opzioni che potresti implementare per questo:

Un'hashmap che utilizzerà il nome della funzione lato-script come chiave stringa e la funzione ptr come valore associato a quella chiave.

exported_funcs["do_thing"] = &native_do_thing;
Comunemente utilizzato nei linguaggi di scripting di sistemi embedded come Pawn, è possibile utilizzare i dati di script per memorizzare il puntatore della funzione. Quando si "registra" la funzione, si itera la tabella delle funzioni esportate dello script e si cerca il nome che la funzione esportata registrerà come; una volta trovato il nome, sovrascrivi i dati di questo script (non il file di script stesso ma i dati di memoria di script caricati) e hai essenzialmente memorizzato il puntatore della funzione nativa.

FuncPtrType **table_entry = get_script_entry_ptr(func_name); *table_entry = func_ptr;

Consiglio vivamente che, per la seconda opzione, si dia alla tabella una dimensione sufficiente per contenere le dimensioni dei puntatori di tutte le architetture, in particolare la voce dovrebbe essere di 8 byte.