Ventajas y desventajas de estructurar todo el código a través de clases y compilar en clases (como Java)

Editar: mi idioma permite la herencia múltiple, a diferencia de Java.

Comencé a diseñar y desarrollar mi propio lenguaje de programación con fines educativos, recreativos y potencialmente útiles.

Al principio, decidí basarlo en Java.

Esto implicaba que todo el código se escribiría en forma de clases, y que el código se compila en clases, que son cargadas por la VM.

Sin embargo, he excluido características tales como interfaces y clases abstractas, porque no encontré necesidad de ellas. Parecían estar aplicando un paradigma, y me gustaría que mi lenguaje no lo haga. Sin embargo, quería mantener las clases como la unidad de compilación, porque parecía conveniente implementarlas, familiares, y simplemente me gustó la idea.

Luego me di cuenta de que básicamente me quedaba con un sistema de módulos, donde las clases podían usarse como "espacios de nombres", proporcionando constantes y funciones usando la staticdirectiva, o como plantillas para objetos que necesitan ser instanciados (propósito "real" de las clases en otros idiomas)

Ahora me pregunto: ¿cuáles son las ventajas y desventajas de tener clases como unidades de compilación?

Además, cualquier comentario general sobre mi diseño sería muy apreciado. Puede encontrar una publicación informativa sobre mi idioma aquí: http://www.yannbane.com/2012/12/kava.html .

— jcora
fuente

Si las clases también incluyen espacios de nombres que desambiguan todos los identificadores en la clase, entonces tiene una unidad de compilación completamente autónoma. Esa clase se puede compilar correctamente, siempre que se puedan satisfacer todas las dependencias de otras clases ya sea por compilación o por referencia a una clase compilada en un ensamblado. Tal atomicidad debería tener ventajas obvias.

— Robert Harvey

Nota al margen: si elimina las clases abstractas y las interfaces, está obligando a las personas a usar la herencia para subtipos y polimorfismos. Eso seguramente producirá un código horrible. Además, a menos que agregue herencia múltiple (y maneje los problemas asociados), está increíblemente restringido.

@delnan: En realidad, aún puedes usar la composición para desarrollar la funcionalidad.

— Robert Harvey

@RobertHarvey Supongo que estás hablando de restricciones por falta de herencia múltiple. Sí, uno puede emularlo con suficiente composición, pero difícilmente lo consideraría aceptable. Por ejemplo, un objeto que normalmente implementaría dos interfaces tendría que implementarse dos veces, en subclases de clases base distintas (y si bien ambas implementaciones podrían delegarse en una clase común, eso sigue siendo una carga de código adicional y no se puede convertir fácilmente una instancia de uno en una instancia del otro).

@delnan: ¿Qué tiene de malo usar la herencia para subtipar y polimorfismo? Para eso es la herencia ...

— Mason Wheeler

Respuestas:

¿Cuáles son los beneficios de tener clases como unidades de compilación?

Puede reducir la complejidad del lenguaje. No hay necesidad de diferentes construcciones, todo se trata igual. En ciertos diseños (aunque no el suyo parece), se beneficia de no tener estática y los problemas de diseño que tienden a encontrar (problemas de orden de inicialización, limitaciones de concurrencia, incomodidad con los genéricos / clases de tipo). También permite algunos beneficios del concepto de módulo, como instancias de módulo aisladas para sandboxing o paralelización; y la tipificación de módulos donde las dependencias se ajustan a alguna interfaz y se puede instanciar y colocar todo el módulo de implementación.

Dicho esto, el concepto tiende a tener más problemas que no. Siendo realistas, no puedes tratar todo de la misma manera, ya que las clases de 'nivel superior' necesitan reglas especiales como tener un constructor predeterminado (o de lo contrario te encontrarás con problemas extraños al girarlos). La modularidad de las unidades de compilación también tiende a ser realmente incómoda. ¿Cómo hace referencia una clase a otras cuando son solo clases? ¿Cómo se tratan esas dependencias y cómo se determina el orden correcto para hacer girar las clases? ¿Cómo se asegura de que las diferentes partes de la aplicación reutilicen las referencias de clase duplicadas (o cómo maneja las instancias duplicadas si esa es la semántica que desea)?

Después de analizarlo, me encontré con muchos problemas con las dependencias, el alcance de las cosas correctamente y las preocupaciones de inicialización. Terminas encontrando problemas que hacen que las 'clases de nivel superior' sean especiales, y muchas limitaciones para que funcionen que terminan convirtiéndolas en espacios de nombres simples.

— Telastyn
fuente

Solo planeo tener una sola clase de nivel superior, la Object. Me doy cuenta de que probablemente necesitaré un comportamiento especial para ello, pero mientras sea un caso aislado, estoy de acuerdo con eso. Sin embargo, no creo que tenga problemas de dependencia. Hay un conjunto de clases que se cargan cuando se inicia la máquina virtual, algunas de ellas se implementan de forma nativa (la clase del sistema), pero todas se heredan de Object. Una vez que todo se ha cargado, el KVM carga la clase que se le ordenó cargar y resuelve las dependencias. Sin embargo, estoy interesado, ¿qué problemas introducen las estadísticas?

— jcora

@yannbane: no objectme refiero a las clases que se comportan como módulos en lugar de clases internas que no son necesariamente públicas fuera de su unidad de compilación. 'Resuelve las dependencias' se convierte en un nido de avispas gigantes en los detalles si desea algún tipo de comportamiento de estilo DLL; ymmv. En cuanto a la estática .

— Telastyn

Ese comportamiento similar a un módulo se lograría mediante el uso de métodos / variables estáticas, ¿verdad? ¿Es malo, en lugar de crear una clase que pueda ser instanciada, crear una clase que solo tenga miembros y métodos estáticos? Vi ese artículo, sin embargo, no creo que se aplique a miembros estáticos constantes , ni a métodos estáticos. Por ejemplo, no veo nada de malo en crear una Mathclase, que en realidad es un módulo con métodos estáticos y un miembro doble estático constante llamado Pi.

— jcora

@yannbane - No, en realidad no. Los módulos son módulos porque son instanciables. De lo contrario, solo tiene espacios de nombres de estilo C ++. Una vez que limite sus clases de nivel superior para que sean espacios de nombres de estilo C ++, ya no son realmente clases.

— Telastyn

Hm, todavía estoy bien y realmente no veo el problema con la creación de módulos con clases. Y sí, los módulos actúan como espacios de nombres, especialmente los módulos de Python.

— jcora

En lugar de responder a esta pregunta, subiré un nivel y sugeriré estudiar el MIT OpenCourseWare , particularmente 6.035 (Ingeniería del lenguaje informático). Esto explicará toda la problemática, para que no sienta la tentación de hacer preguntas como esta nuevamente.

Ingeniería del lenguaje informático

El único requisito previo es Java.

http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-035-computer-language-engineering-spring-2010/lecture-notes/

Descripción del curso

Este curso analiza los problemas asociados con la implementación de lenguajes de programación de nivel superior. Los temas cubiertos incluyen: conceptos fundamentales, funciones y estructuras de compiladores, la interacción de la teoría y la práctica, y el uso de herramientas en la creación de software. El curso incluye un proyecto de varias personas sobre diseño e implementación del compilador.

— mosquito
fuente