Avantages et inconvénients de la structuration de tout le code via des classes et de la compilation en classes (comme Java)

Edit: mon langage permet l'héritage multiple, contrairement à Java.

J'ai commencé à concevoir et à développer mon propre langage de programmation à des fins éducatives, récréatives et potentiellement utiles.

Au début, j'ai décidé de le baser sur Java.

Cela impliquait que tout le code serait écrit sous forme de classes, et que le code se compile en classes, qui sont chargées par la machine virtuelle.

Cependant, j'ai exclu des fonctionnalités telles que les interfaces et les classes abstraites, car je n'en ai trouvé aucun besoin. Ils semblaient appliquer un paradigme, et j'aimerais que ma langue ne le fasse pas. Je voulais garder les classes comme unité de compilation, car cela semblait pratique à implémenter, familier, et j'aimais juste l'idée.

Ensuite, j'ai remarqué qu'il me restait essentiellement un système de modules, où les classes pouvaient être utilisées soit comme "espaces de noms", fournissant des constantes et des fonctions à l'aide de la staticdirective, soit comme modèles pour les objets qui doivent être instanciés (objectif "réel" des classes dans d'autres langues).

Maintenant, je me demande: quels sont les avantages et les inconvénients d'avoir des classes comme unités de compilation?

De plus, tout commentaire général sur ma conception serait très apprécié. Un article informatif sur ma langue peut être trouvé ici: http://www.yannbane.com/2012/12/kava.html .

java programming-languages design language-design jcora
la source

Si les classes incluent également des espaces de noms qui désambiguïsent tous les identificateurs de la classe, vous disposez alors d'une unité de compilation complètement autonome. Cette classe peut être compilée avec succès, à condition que toutes les dépendances à d'autres classes puissent être satisfaites soit par compilation, soit par référence à une classe compilée dans un assembly. Une telle atomicité devrait présenter des avantages évidents.

Robert Harvey

Note latérale: si vous supprimez les classes abstraites et les interfaces, vous forcez les gens à utiliser l'héritage pour le sous-typage et le polymorphisme. Cela ne peut que produire un code affreux. De plus, sauf si vous ajoutez plusieurs héritages (et gérez les problèmes associés), c'est incroyablement restreint.

@delnan: En fait, vous pouvez toujours utiliser la composition pour créer des fonctionnalités.

Robert Harvey

@RobertHarvey Je suppose que vous parlez de restrictions par manque d'héritage multiple. Oui, on peut l'imiter avec suffisamment de composition, mais je ne le considérerais guère comme acceptable. Par exemple, un objet qui implémenterait généralement deux interfaces devrait être implémenté deux fois, dans des sous-classes de classes de base distinctes (et bien que les deux implémentations puissent se déléguer à une classe commune, cela reste une merde de code supplémentaire et vous ne pouvez pas facilement tourner une instance de l'un dans une instance de l'autre).

@delnan: Quel est le problème avec l'utilisation de l'héritage pour le sous-typage et le polymorphisme? C'est à ça que sert l'héritage ...

Mason Wheeler

Réponses:

quels sont les avantages d'avoir des classes comme unités de compilation?

Cela peut réduire la complexité de la langue. Pas besoin de constructions différentes, tout est traité de la même façon. Dans certaines conceptions (même si ce n'est pas la vôtre semble-t-il), vous bénéficiez de l'absence de statique et des problèmes de conception dans lesquels ils ont tendance à se heurter (problèmes d'ordre d'initialisation, limitations de concurrence, maladresse avec les génériques / classes de type). Il permet également certains avantages du concept de module comme des instances de module isolées pour le sandboxing ou la parallélisation; et le typage de module où les dépendances correspondent à une certaine interface et la valeur entière du module d'implémentation peut être instanciée et ajoutée.

Cela dit, le concept a tendance à avoir plus de problèmes que non. De manière réaliste, vous ne pouvez pas tout traiter de la même manière, car les classes de «haut niveau» ont besoin de règles spéciales comme avoir un constructeur par défaut (ou bien vous rencontrez des problèmes étranges en les faisant tourner). La modularité des unités de compilation tend également à devenir très gênante. Comment une classe référence-t-elle même les autres quand ce ne sont que des classes? Comment ces dépendances sont-elles traitées et comment déterminez-vous l'ordre correct de rotation des classes? Comment vous assurez-vous que les références de classe en double sont réutilisées par différentes parties de l'application (ou comment gérez-vous les instances en double si c'est la sémantique que vous souhaitez)?

Après l'avoir examiné, j'ai rencontré beaucoup de problèmes avec les dépendances, l'étendue des choses correctement et les problèmes d'initialisation. Vous finissez par rencontrer des problèmes qui rendent les «classes de niveau supérieur» spéciales, et de nombreuses limitations pour les faire fonctionner qui finissent par les transformer en espaces de noms simples.

Telastyn
la source

Je prévois d'avoir une seule classe de haut niveau, la Object. Je me rends compte que j'aurai probablement besoin d'un comportement spécial pour cela, mais tant qu'il s'agit d'un cas isolé, je suis d'accord avec ça. Je ne pense pas que j'aurai des problèmes de dépendance. Il existe un ensemble de classes qui sont chargées au démarrage de la machine virtuelle, certaines d'entre elles sont implémentées en mode natif (la classe System), mais elles héritent toutes d'Object. Une fois que tout a été chargé, le KVM charge la classe qu'il a été chargé de charger et calcule les dépendances. Cependant, je suis intéressé, quels problèmes la statique introduit-elle?

jcora

@yannbane - Je ne veux pas dire object, je veux dire des classes qui se comportent comme des modules plutôt que des classes internes qui ne sont pas nécessairement publiques en dehors de leur unité de compilation. «Fonctionne sur les dépendances» se transforme en un nid de frelon géant dans les détails si vous voulez une sorte de comportement de style DLL; ymmv. Quant à statique .

Telastyn

Ce comportement de type module serait atteint grâce à l'utilisation de méthodes / variables statiques, non? Est-il mauvais, au lieu de créer une classe qui peut être instanciée, de créer une classe qui n'a que des membres et des méthodes statiques? J'ai vu cet article, cependant, je ne pense pas qu'il s'applique aux membres statiques constants , ni aux méthodes statiques. Par exemple, je ne vois rien de mal à créer unMath classe, qui est en fait un module avec des méthodes statiques et un double membre statique constant appelé Pi.

jcora

@yannbane - Non, pas vraiment. Les modules sont des modules car ils sont instanciables. Sinon, vous n'avez que des espaces de noms de style C ++. Une fois que vous limitez vos classes de niveau supérieur à des espaces de noms de style C ++, elles ne sont plus vraiment des classes.

Telastyn

Hm, je suis toujours OK et je ne vois pas vraiment le problème avec la création de modules avec des classes. Et oui, les modules agissent comme des espaces de noms, en particulier les modules Python.

jcora

Au lieu de répondre à cette question, je vais monter d'un niveau et suggérer d'étudier le MIT OpenCourseWare , en particulier 6.035 (Computer Language Engineering). Cela expliquera toute la problématique, afin que vous ne soyez pas tenté de poser à nouveau des questions comme celle-ci.

Ingénierie du langage informatique

Le seul pré-requis est Java.

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

Description du cours

Ce cours analyse les problèmes liés à la mise en œuvre de langages de programmation de niveau supérieur. Les sujets traités comprennent: les concepts fondamentaux, les fonctions et les structures des compilateurs, l'interaction de la théorie et de la pratique et l'utilisation d'outils dans la construction de logiciels. Le cours comprend un projet de plusieurs personnes sur la conception et la mise en œuvre du compilateur.

moucheron
la source