coding module coding-style naming-conventions d

module - c# coding standards



Organizar módulos en un proyecto D (3)

Vengo de entornos Java y el problema del embalaje es el siguiente:

Puedo tener muchos archivos bajo el mismo paquete, decir com.parobay.io . Entonces puedo distribuir esto como una biblioteca, y los usuarios lo usarán así:

import com.parobay.io.Input; import com.parobay.io.Output;

o

import com.parobay.io.*; // to import everything

Entonces puedo tener un solo "módulo ( com.parobay.io ) y clases definidas en múltiples archivos.

Entonces, ¿cómo puedo lograr lo mismo en D? ¿Tengo que crear un directorio com/parobay/io y colocar dos archivos llamados Input.d y Output.d o hay una manera más inteligente?

En Java, las reglas son muy estrictas, por lo que es difícil equivocarse. En D hay muchas posibilidades. Entonces, ¿hay alguna convención, como una clase por archivo, o un nombre de archivo igual al nombre de la clase?


La comunidad D tiene tres alternativas ampliamente aceptadas.

  1. Escriba un módulo llamado all.d que incluya todos los módulos de su paquete. (Literalmente ''*'' -> ''todo''). Después de eso, simplemente import com.paroboy.io.all;

  2. Veo más y más que los desarrolladores D usan _ para esto. Entonces escriben un módulo llamado _.d para este propósito. De manera similar a # 1, usted import com.paroboy.io._;

  3. Una adición relativamente nueva al lenguaje de programación D es el módulo package.d , que se puede usar para importar el paquete. Más sobre esto en el siguiente DIP: http://wiki.dlang.org/DIP37 . Si recuerdo bien, DMD lo soporta desde v2.064. (Documentación: http://dlang.org/module#PackageModule )

Yo mismo uso el enfoque n. ° 1 porque es obvio lo que está sucediendo. Mientras que los números 2 y 3 pueden ser confusos para las personas que leen el archivo fuente D, especialmente el tercero. Una pregunta válida que alguien puede hacer: "¿Qué diablos estoy importando, paquete? ¡¡Pero la import es solo para módulos!"

Aunque nada te impide tener un módulo separado por clase, no lo recomendaría. D es un lenguaje verdaderamente modular, así que aprovéchalo. Agrupe todos sus tipos en un solo módulo D. Ese es mi consejo, y esa es la "forma D".

NOTA: Hay una (gran) diferencia semántica entre el "módulo" de Java y un módulo D, como probablemente ya haya notado. Principalmente soy un programador de Java, así que sé lo confuso que esto puede ser para los programadores de Java que están jugando con las clases de D. Java en el mismo paquete, que a menudo aprovechan el acceso a nivel de paquete. Sin embargo, las clases dentro del mismo módulo se comportan como "amigos" en C ++.

Hablando de los módulos de Java , se suponía que iban a venir con Java 8 (¡módulos reales!), Pero se pospusieron y se espera que se incluyan en Java 9.

ACTUALIZACIÓN: Llegamos a la conclusión de que, después de un chat en FreeNode (IRC) con algunos miembros de D-Programming-Language , ahora es seguro usar el atributo del package . Se comporta como dice la especificación.


No use dos archivos separados para sus clases de Input y Output . En su lugar, coloque ambas clases en un solo archivo, parobay/io.d (correspondiente al módulo parobay.io ).

Definitivamente no es la convención limitarse a una sola clase por archivo. Los módulos D son para agrupar el código de la funcionalidad relacionada. Cuando alguien import parobay.io; , esperan obtener todas las clases de parobay.io , funciones de utilidad y cualquier otra cosa relevante. Es similar a la import com.parobay.io.*; de Java import com.parobay.io.*; .

Si alguien realmente quiere importar partes específicas de su módulo, puede usar importaciones selectivas:

import parobay.io: Input; // Just the Input class of the parobay.io module. import parobay.io: Output; // Just the Output class. import parobay.io: Input, Output; // Just the Input and Output classes.

Hay algunas cosas adicionales a tener en cuenta sobre esto.

  • Los nombres de paquetes y módulos son convencionalmente minúsculas.
  • Facilita la vida de todos si la ruta del archivo coincide exactamente con su nombre completo de módulo. Por ejemplo, el módulo foo.bar.baz debe estar en el archivo foo/bar/baz.d
  • En mi experiencia, es raro que un módulo D tenga el nombre de un nombre de dominio. Puede prefijar los nombres de sus módulos con com o org o net si realmente lo desea, pero no se espera que estén en Java.

La respuesta de Adam D. Ruppe tiene algunos puntos importantes acerca de las declaraciones explícitas de los módulos y la visibilidad de los miembros de la clase. También vale la pena leer las páginas de módulos y estilos en el sitio web oficial de D.


Puede elegir hacerlo básicamente igual que Java, aunque recuerde estos elementos:

  • import foo.* no funciona en D, pero PUEDE crear un archivo llamado package.d en el directorio que enumera manualmente public import foo.Input; public import foo.Output; public import foo.Input; public import foo.Output; etc. que le permite importar todo el paquete.

  • SIEMPRE ponga un module com.parobay.io.Input; o cualquier línea en la parte superior de cualquier archivo que se importe. No espere que solo funcione en función de la estructura del directorio y el nombre del archivo. La estructura del directorio en realidad no es estrictamente necesaria, es solo una convención para encontrar fácilmente el archivo. La línea de module en la parte superior con el nombre es la cosa autorizada que el compilador verifica.

  • Los módulos D a menudo tienen todos los nombres en minúscula, pero puede usar mayúsculas si lo desea. Creo que es agradable usar un nombre en minúsculas como el nombre de la clase, por lo que puede llamar al módulo io.input y la clase Input . El motivo de esta convención es que a veces el nombre del archivo se pierde al transferir de un sistema a otro. Pero los desarrolladores son muy conscientes del caso, por lo que en la práctica cualquiera de las dos cosas debería funcionar.

  • Una clase por archivo funcionará bien o puede juntar dos clases muy juntas en el mismo archivo (tendrán acceso a los miembros privados de los demás si están en el mismo archivo).

Consulte esta página para obtener más información: http://dlang.org/module especialmente busque el encabezado "Módulo de paquete"