objectionary/eo : ce que le README permet réellement d'évaluer

Ce qu'EO retire de l'orientation objet

EO est un langage orienté objet pur et expérimental fondé sur le phi-calcul. Le README commence en disant que les langages semi-OOP populaires, notamment Java, Ruby, C++, Python et C#, ne sont pas assez bons, et que même Smalltalk, Eiffel, Self et Io contiennent des choses que les auteurs ne tolèrent pas. La liste comprend les types, les classes, les méthodes ou attributs statiques, l'héritage d'implémentation, la mutabilité, NULL, la portée globale, le transtypage, la réflexion, les types scalaires et primitifs de données, les annotations, les opérateurs, les traits et mixins, ainsi que les instructions de contrôle de flux comme `for`, `while` et `if`. Chaque élément renvoie à un essai expliquant l'objection. Le README ne dit pas quand EO pourrait sortir de la phase expérimentale ni comment il est utilisé en production. Lecture ciblée 1 de objectionary/eo : ce passage est rattaché à EO.

Dans objectionary/eo, le repère EO donne une limite de lecture précise pour la section 1. Le README décrit EO comme une entrée, un composant ou une contrainte du projet, sans fournir ici une promesse générale de résultat. Le repère Xmir permet de poursuivre l'examen dans le dépôt avec le vocabulaire propre à eo. Cette distinction évite de transformer une fonction documentée en garantie de compatibilité. Elle compte pour une équipe qui doit choisir entre une intégration ciblée et une solution plus large. La licence MIT encadre la réutilisation du code, tandis que le README reste la source pour les conditions techniques. Repère éditorial 1.

Dans objectionary/eo, le repère XAO donne une limite de lecture précise pour la section 4. Le README décrit XAO comme une entrée, un composant ou une contrainte du projet, sans fournir ici une promesse générale de résultat. Le repère org.eolang permet de poursuivre l'examen dans le dépôt avec le vocabulaire propre à eo. Cette distinction évite de transformer une fonction documentée en garantie de compatibilité. Elle compte pour une équipe qui doit choisir entre une intégration ciblée et une solution plus large. La licence MIT encadre la réutilisation du code, tandis que le README reste la source pour les conditions techniques. Repère de comparaison 1.

Exécuter l'exemple hello world

La section de démarrage rapide demande d'installer Java SE et npm, puis d'installer la commande `eoc` avec `npm install -g eolang@0.37.1`. Un programme minimal est un objet nommé `app` dans un fichier `app.eo` ; son attribut `@` est une copie de `stdout` avec la chaîne `"Hello, world!\n"` comme argument. Compilez avec `eoc --easy link`, puis exécutez avec `eoc --easy --alone dataize app`. L'indentation est significative, comme en Python. Le README montre aussi une notation horizontale avec des crochets pour grouper les arguments. C'est le seul exemple complet et exécutable fourni par le README. Lecture ciblée 2 de objectionary/eo : ce passage est rattaché à Xmir.

Dans objectionary/eo, le repère Xmir donne une limite de lecture précise pour la section 2. Le README décrit Xmir comme une entrée, un composant ou une contrainte du projet, sans fournir ici une promesse générale de résultat. Le repère Maven permet de poursuivre l'examen dans le dépôt avec le vocabulaire propre à eo. Cette distinction évite de transformer une fonction documentée en garantie de compatibilité. Elle compte pour une équipe qui doit choisir entre une intégration ciblée et une solution plus large. La licence MIT encadre la réutilisation du code, tandis que le README reste la source pour les conditions techniques. Repère éditorial 2.

Dans objectionary/eo, le repère org.eolang donne une limite de lecture précise pour la section 5. Le README décrit org.eolang comme une entrée, un composant ou une contrainte du projet, sans fournir ici une promesse générale de résultat. Le repère objects permet de poursuivre l'examen dans le dépôt avec le vocabulaire propre à eo. Cette distinction évite de transformer une fonction documentée en garantie de compatibilité. Elle compte pour une équipe qui doit choisir entre une intégration ciblée et une solution plus large. La licence MIT encadre la réutilisation du code, tandis que le README reste la source pour les conditions techniques. Repère de comparaison 2.

Objets abstraits, copies et décoration

Les programmes EO sont construits à partir d'objets abstraits. Un objet abstrait ne peut pas être utilisé directement ; il faut créer une copie avec les arguments requis. Le README montre `stdout "Hello, world!"` comme copie simple, et une copie plus complexe de `printf` qui reçoit une chaîne de format et un tuple. L'attribut spécial `@` désigne la décoration : un objet décore un autre objet et se comporte comme lui, car tous les attributs de l'objet décoré deviennent des attributs du décorateur. Cela remplace l'héritage d'implémentation. Le README inclut un exemple de boucle utilisant `malloc.empty`, `seq`, `while` et `stdout`, et affiche une petite table de multiplication. Aucune autre construction de contrôle de flux n'existe parce que le langage les supprime. Lecture ciblée 3 de objectionary/eo : ce passage est rattaché à Maven.

Dans objectionary/eo, le repère Maven donne une limite de lecture précise pour la section 3. Le README décrit Maven comme une entrée, un composant ou une contrainte du projet, sans fournir ici une promesse générale de résultat. Le repère XAO permet de poursuivre l'examen dans le dépôt avec le vocabulaire propre à eo. Cette distinction évite de transformer une fonction documentée en garantie de compatibilité. Elle compte pour une équipe qui doit choisir entre une intégration ciblée et une solution plus large. La licence MIT encadre la réutilisation du code, tandis que le README reste la source pour les conditions techniques. Repère éditorial 3.

Dans objectionary/eo, le repère objects donne une limite de lecture précise pour la section 6. Le README décrit objects comme une entrée, un composant ou une contrainte du projet, sans fournir ici une promesse générale de résultat. Le repère LICENSE permet de poursuivre l'examen dans le dépôt avec le vocabulaire propre à eo. Cette distinction évite de transformer une fonction documentée en garantie de compatibilité. Elle compte pour une équipe qui doit choisir entre une intégration ciblée et une solution plus large. La licence MIT encadre la réutilisation du code, tandis que le README reste la source pour les conditions techniques. Repère de comparaison 3.

Grammaire, XMIR et pipeline du compilateur

La grammaire est définie dans `eo-parser/PARSER_SPEC.md`, une classification ligne par ligne pilotée par spécification de toutes les formes légales, avec des règles numérotées (`R-N.M`) que l'implémentation du parseur référence directement. Le parseur de référence se trouve dans `eo-parser/src/main/java/org/eolang/parser/` et convertit le code source EO en XMIR en un seul passage, sans AST intermédiaire. XMIR est un dialecte XML et sert de format pivot unique entre l'analyse et la génération de code ; un schéma XSD le régit. Toutes les transformations, que ce soit la normalisation à l'analyse ou la génération de code, sont implémentées comme des pipelines de feuilles de style XSLT 2.0 plutôt que comme des passes de visiteurs. Le README dit que cela rend chaque état intermédiaire inspectable avec des outils XML standard et testable indépendamment. Lecture ciblée 4 de objectionary/eo : ce passage est rattaché à XAO.

Dans objectionary/eo, le repère XAO donne une limite de lecture précise pour la section 4. Le README décrit XAO comme une entrée, un composant ou une contrainte du projet, sans fournir ici une promesse générale de résultat. Le repère org.eolang permet de poursuivre l'examen dans le dépôt avec le vocabulaire propre à eo. Cette distinction évite de transformer une fonction documentée en garantie de compatibilité. Elle compte pour une équipe qui doit choisir entre une intégration ciblée et une solution plus large. La licence MIT encadre la réutilisation du code, tandis que le README reste la source pour les conditions techniques. Repère éditorial 4.

Dans objectionary/eo, le repère LICENSE donne une limite de lecture précise pour la section 7. Le README décrit LICENSE comme une entrée, un composant ou une contrainte du projet, sans fournir ici une promesse générale de résultat. Le repère EO permet de poursuivre l'examen dans le dépôt avec le vocabulaire propre à eo. Cette distinction évite de transformer une fonction documentée en garantie de compatibilité. Elle compte pour une équipe qui doit choisir entre une intégration ciblée et une solution plus large. La licence MIT encadre la réutilisation du code, tandis que le README reste la source pour les conditions techniques. Repère de comparaison 4.

Intégration de build et benchmark

EO compile dans le cadre d'un cycle de vie Maven via `eo-maven-plugin`, qui expose des mojos tels que `parse`, `assemble` et `transpile`, exécutés pendant les phases `generate-sources` et `process-sources`. Les objets EO externes sont résolus depuis Objectionary, un registre hébergé sur Git d'objets canoniques, et non depuis un dépôt d'artefacts binaires ; le mojo `MjPull` récupère les sources `.eo` manquantes au moment de la construction et les met en cache localement. La bibliothèque standard est écrite en EO elle-même et se trouve dans `eo-runtime/src/main/eo/`. Le README inclut un benchmark des temps des feuilles de style XSL lors d'un `mvn install` : `to-java.xsl` a pris 54412 ms, le total était de 158017 ms, mesurés dans un job GitHub Actions le 2026-05-08 sur Linux avec 4 CPU. Ce benchmark ne couvre que le coût des feuilles de style, pas les performances du programme de bout en bout. Lecture ciblée 5 de objectionary/eo : ce passage est rattaché à org.eolang.

Dans objectionary/eo, le repère org.eolang donne une limite de lecture précise pour la section 5. Le README décrit org.eolang comme une entrée, un composant ou une contrainte du projet, sans fournir ici une promesse générale de résultat. Le repère objects permet de poursuivre l'examen dans le dépôt avec le vocabulaire propre à eo. Cette distinction évite de transformer une fonction documentée en garantie de compatibilité. Elle compte pour une équipe qui doit choisir entre une intégration ciblée et une solution plus large. La licence MIT encadre la réutilisation du code, tandis que le README reste la source pour les conditions techniques. Repère éditorial 5.

Dans objectionary/eo, le repère EO donne une limite de lecture précise pour la section 8. Le README décrit EO comme une entrée, un composant ou une contrainte du projet, sans fournir ici une promesse générale de résultat. Le repère Xmir permet de poursuivre l'examen dans le dépôt avec le vocabulaire propre à eo. Cette distinction évite de transformer une fonction documentée en garantie de compatibilité. Elle compte pour une équipe qui doit choisir entre une intégration ciblée et une solution plus large. La licence MIT encadre la réutilisation du code, tandis que le README reste la source pour les conditions techniques. Repère de comparaison 5.

Contribuer et ce que le README laisse ouvert

Les contributions sont des pull requests vers `master`. Le README demande aux contributeurs d'exécuter `mvn clean install -Pqulice`, ce qui nécessite Maven 3.3+ et Java 21+ ; une construction sans ce profil nécessite Java 17+. Les noms de branches doivent correspondre au numéro d'issue, les messages de commit doivent commencer par `fix(#42):`, et les pull requests doivent rester entre 40 et 100 lignes ajoutées plus supprimées, les changements plus importants étant découpés avec PDD. Le README ne contient pas de texte de licence, bien que les métadonnées du dépôt indiquent MIT ; sans le texte de licence, il est impossible de dire ce que la licence accorde en matière de garantie ou de support. Il ne précise pas non plus si le projet a une politique de sécurité, un code de conduite ou un processus de publication stable. Lecture ciblée 6 de objectionary/eo : ce passage est rattaché à objects.

Dans objectionary/eo, le repère objects donne une limite de lecture précise pour la section 6. Le README décrit objects comme une entrée, un composant ou une contrainte du projet, sans fournir ici une promesse générale de résultat. Le repère LICENSE permet de poursuivre l'examen dans le dépôt avec le vocabulaire propre à eo. Cette distinction évite de transformer une fonction documentée en garantie de compatibilité. Elle compte pour une équipe qui doit choisir entre une intégration ciblée et une solution plus large. La licence MIT encadre la réutilisation du code, tandis que le README reste la source pour les conditions techniques. Repère éditorial 6.

Dans objectionary/eo, le repère Xmir donne une limite de lecture précise pour la section 9. Le README décrit Xmir comme une entrée, un composant ou une contrainte du projet, sans fournir ici une promesse générale de résultat. Le repère Maven permet de poursuivre l'examen dans le dépôt avec le vocabulaire propre à eo. Cette distinction évite de transformer une fonction documentée en garantie de compatibilité. Elle compte pour une équipe qui doit choisir entre une intégration ciblée et une solution plus large. La licence MIT encadre la réutilisation du code, tandis que le README reste la source pour les conditions techniques. Repère de comparaison 6.

Conclusion éditoriale

Le projet s'adresse aux personnes dont le besoin correspond à EO et qui acceptent les limites écrites dans le README. Il convient moins à une équipe qui attend une garantie absente des sources. Avant décision, vérifiez Xmir avec la commande ou le fichier indiqué par eo, puis contrôlez le résultat propre à Maven.

Sources officielles

1. Official documentation
2. Official README
3. Project repository
4. Release notes