Sistema de módulos para el lenguaje OOP

8

Estoy diseñando un lenguaje de programación OO simple.

Es mecanografiado, compilado y ejecutado estáticamente por una máquina virtual, similar a Java.

La diferencia es que no quiero tener un énfasis tan fuerte en la POO. El código en sí se asemejará principalmente a C ++ (clases, funciones y variables permitidas en el alcance del archivo).

Una de las cosas que necesito tener es un sistema de módulos. Tengo lo siguiente resuelto:

  1. Cada archivo es un módulo (una vez compilado), como Python
  2. Los programadores deben importar un módulo con la palabra clave import , lo que hace que el compilador busque módulos en los directorios estándar y el directorio de archivos (la VM también debe hacer esto en tiempo de ejecución)

Y ahora no tengo idea de cómo debo introducir el concepto de submódulos y jerarquía de módulos.

Una opción, por ejemplo, es depender de la jerarquía de directorios, de modo que import engine.graphics.renderer esperaría encontrar un directorio llamado "motor" en el directorio de trabajo, y dentro de un directorio llamado "gráficos", con un módulo llamado "renderer".

¿Cuáles son los inconvenientes de este diseño? ¿Me estoy perdiendo algo?

    
pregunta Aber Kled 01.10.2013 - 19:05

2 respuestas

2

Eche un vistazo a la organización / jerarquía de paquetes / módulos de Python, y especialmente en el aspecto histórico, las adiciones más importantes a lo largo de los años, sobre todo las más recientes. Probablemente, no tiene sentido inventar la rueda.

No sé qué tan lejos quieres ir con tu idioma, por ejemplo,

  • ¿Desea que los módulos de bytecode se lean desde zip?
  • ¿Cómo separa los módulos / bibliotecas para diferentes versiones de intérpretes?
  • ¿Planeas hacerlo sin par con las distribuciones?
  • No olvide la facilidad de distribución del lenguaje (piense en los nombres / pypi: cada plataforma / idioma tiene la suya, no siempre es buena)

Supongo que Java puede ser otro ejemplo interesante. Las cosas también se pueden aprender de la manera de Erlang (por ejemplo, enlace ).

Hay muchos problemas de diseño (algunos mencionados anteriormente) si planea ver su lenguaje de programación un día. Afortunadamente, hay grandes ejemplos por ahí.

Algunas direcciones deben ir dirigidas al diseño del módulo de lenguaje de programación / paquete / biblioteca:

  • código intuitivo para escribir y usar el módulo
  • objetos de módulo / paquete en el código
  • capacidades de introspección del módulo / paquete
  • encapsulación de módulo / paquete (¿cómo ocultar detalles innecesarios?)
  • uso de interfaces / archivos de cabecera?
  • sistema de despacho de granito fino que pueden usar tanto los utils de distribución propios del idioma como los utils a nivel del sistema (evite el "infierno de DLL")
  • lugares de almacenamiento para módulos compilados por bytes
  • sistema de configuración, que automatiza la compilación de módulos "puros" y módulos / dependencias
  • lugar canónico de código compilado, pruebas, documentación, activos en su módulo
respondido por el Roman Susi 23.05.2017 - 14:40
2

En primer lugar, supongamos que asigna su modelo de espacio de nombres a otro espacio de nombres, como el sistema de archivos, como sugirió. Segundo, asumo que los módulos pueden importar otros módulos. En otras palabras, engine.graphics.renderer podría muy bien contener una línea como import circle.arc . Eso plantea dos cuestiones:

  • ¿Dónde buscaría la máquina virtual circle.arc ? De acuerdo con el sistema de archivos mappimg mencionado, debería haber un directorio como /etc/mylang/modules/circle/arc ( /etc/mylang/modules es la raíz de la estructura de su módulo) .

  • ¿Cómo haría una referencia de aplicación circle.arc : por import ing circle.arc o engine.graphics.render.circle.arc ? El primero "estropearía" (si no arruinaría) la jerarquía, porque circle.arc es claramente un submódulo de engine.graphics.renderer , y el segundo implicaría que debería haber un /etc/mylang/modules/engine/graphics/renderer/circle/arc en su sistema de archivos, colocando circle.arc en dos ubicaciones simultáneamente.

Habiendo dicho eso, y si decides seguir con el enfoque del espacio de nombres, asignarlo al sistema de archivos me parece demasiado restrictivo. Creo que los módulos pueden residir en diferentes tipos de lugares (incluso archivos zip, como ya se mencionó, incluso urls). La VM comenzaría buscando una entrada en algún tipo de índice (tal vez un archivo de configuración) que asignaría el espacio de nombres a las ubicaciones reales de los módulos.

    
respondido por el geomagas 12.10.2013 - 19:52