Sistema di moduli per linguaggio OOP

8

Sto progettando un semplice linguaggio di programmazione OO.

È tipizzato staticamente, compilato ed eseguito da una VM, simile a Java.

La differenza è che non voglio avere un'enfasi così strong su OOP. Il codice stesso somiglierà per lo più al C ++ (classi, funzioni e variabili permesse nello scope del file).

Una delle cose che devo avere è un sistema modulare. Ho capito quanto segue:

  1. Ogni file è un modulo (una volta compilato) - come Python
  2. I programmatori devono importare un modulo con la parola chiave import , che fa in modo che il compilatore cerchi i moduli nelle directory standard e nella directory dei file (anche la VM deve farlo in fase di runtime)

E ora non ho idea di come dovrei introdurre il concetto di sottomoduli e gerarchia dei moduli.

Un'opzione, ad esempio, è dipendere dalla gerarchia della directory, in modo che import engine.graphics.renderer si aspetti di trovare una directory chiamata "engine" nella directory di lavoro e all'interno di una directory chiamata "graphics", con un modulo chiamato "renderer".

Quali sono gli svantaggi di un tale progetto? Mi sto perdendo qualcosa?

    
posta Aber Kled 01.10.2013 - 19:05
fonte

2 risposte

2

Dai un'occhiata alla gerarchia / organizzazione dei pacchetti / moduli di Python e, soprattutto in termini di aspetto storico, le principali aggiunte nel corso degli anni, soprattutto le più recenti. Probabilmente, non ha senso inventare la ruota.

Non so quanto tu voglia andare con la tua lingua, ad esempio

  • Vuoi che i byte dei moduli vengano letti da zip?
  • Come si separano i moduli / le librerie per le diverse versioni dell'interprete?
  • Hai intenzione di renderlo senza distorsioni?
  • Non dimenticare la facilità della distribuzione del linguaggio (pensa a distutils / pypi - ogni piattaforma / lingua ha il suo, non sempre buono)

Suppongo che Java possa essere un altro esempio interessante. Le cose possono essere apprese anche da Erlang (ad es. link ).

C'è un sacco di problemi di progettazione (alcuni di quelli sopra riportati) se si prevede di vedere un giorno il linguaggio di programmazione tradizionale. Fortunatamente, ci sono ottimi esempi là fuori.

Alcune direzioni di programmazione del modulo di linguaggio / pacchetto / struttura del sistema di librerie dovrebbero riguardare:

  • codice intuitivo per scrivere e utilizzare il modulo
  • modulo / pacchetto oggetti nel codice
  • capacità di introspezione di moduli / pacchetti
  • incapsulamento di moduli / pacchetti (come nascondere dettagli non necessari?)
  • uso di interfacce / file di intestazione?
  • sistema di dispacciamento a grana fine, che può utilizzare sia gli strumenti di distribuzione della lingua sia i programmi di utilità a livello di sistema (evitare "l'inferno della DLL")
  • spazi di archiviazione per moduli bytecompiled
  • sistema di installazione, che automatizza la compilazione di moduli "puri" e moduli / dipendenze
  • luogo canonico di codice, test, documentazione, risorse compilati nel modulo
risposta data 23.05.2017 - 14:40
fonte
2

Prima di tutto, supponiamo di mappare il tuo modello con un namespace in un altro spazio dei nomi, come il filesystem, come suggerito. Secondo, suppongo che i moduli possano importare altri moduli. In altre parole, engine.graphics.renderer potrebbe benissimo contenere una riga come import circle.arc . Ciò solleva due problemi:

  • Dove sarebbe la VM alla ricerca di circle.arc ? Secondo il file system mappimg menzionato, dovrebbe esserci una directory come /etc/mylang/modules/circle/arc ( /etc/mylang/modules è la radice della struttura del modulo) .

  • In che modo un'applicazione fa riferimento a circle.arc : di import ing circle.arc o engine.graphics.render.circle.arc ? Il primo dovrebbe "rovinare" (se non rovinare) la gerarchia, perché circle.arc è chiaramente un sottomodulo di engine.graphics.renderer , e il secondo implicherebbe che ci dovrebbe essere un /etc/mylang/modules/engine/graphics/renderer/circle/arc nel tuo filesystem, ponendo circle.arc in due posizioni contemporaneamente.

Detto questo, e se dovessi decidere di adottare l'approccio namespace, mapparlo al filesystem mi sembra troppo restrittivo. Penso che i moduli possano risiedere in tutti i diversi tipi di luoghi (anche i file zip, come già accennato, anche gli URL). La VM inizierebbe cercando una voce in una sorta di indice (magari un file di configurazione) che mapperebbe lo spazio dei nomi alle posizioni effettive dei moduli.

    
risposta data 12.10.2013 - 19:52
fonte