Pourquoi les opérateurs Null-Safe (par exemple «opérateur Elvis») ont-ils été rejetés dans le cadre du «Project Coin» de Java 7?

L'une des fonctionnalités proposées pour le "Project Coin" de Java 7 était "l'opérateur Elvis". Un rapport d'une présentation JavaOne 2009 sur Project Coin le décrit comme tel:

L'une des «petites fonctionnalités» abordées dans cette présentation est ce que l'on appelle «l'opérateur Elvis», une version plus concise de l'opérateur ternaire. Je me retrouve à manquer certaines des fonctionnalités de Groovy lors de l'utilisation de Java traditionnel et ce serait un opérateur que je pourrais utiliser dans les deux langues s'il était ajouté. L'opérateur "Elvis" est pratique pour spécifier une valeur par défaut qui peut être utilisée lorsque l'expression évaluée est nulle. Comme l'opérateur de navigation sécurisée de Groovy, c'est un moyen concis de spécifier comment éviter les null inutiles. J'ai déjà blogué sur la façon dont j'aime éviter l'exception NullPointerException.

Alors que d'autres aspects de Project Coin ont finalement été mis en œuvre, celui-ci ne l'a pas été. Pourquoi l'opérateur Elvis a-t-il finalement été rejeté, bien qu'il ait été présenté à JavaOne comme un candidat probable à l'inclusion?

Pour être clair, je pose spécifiquement des questions sur cet opérateur et la raison pour laquelle il a été rejeté dans le cadre du "Project Coin" de Java 7, étant donné qu'il a été sérieusement envisagé à l'époque. Je soupçonne qu'il existe des listes de diffusion ou autres où les raisons du rejet ont été discutées, mais je n'ai rien trouvé. S'il existe des informations plus générales sur les raisons pour lesquelles il n'est inclus dans aucune version de Java, cela est acceptable mais pas préféré.

java api-design

— Thunderforge
source

esprits suspicieux?

— Ewan

Mot probablement parce qu'il prend en charge et encourage l'utilisation de valeurs nulles en tant que valeurs légitimes et, plus fondamentalement, est contraire aux principes OO car vous vérifiez le type d'un objet avant d'exécuter une méthode.

— JacquesB

À moins que quelqu'un ne déterre des documents explicites (courriels, notes de service, transcriptions) du processus décisionnel ou qu'il ait participé directement à la décision, nous ne pouvons pas vraiment connaître la réponse ici. Par exemple, la réponse de Robert n'est qu'une spéculation et des considérations générales sur la conception du langage, et non une raison factuelle et spécifique pour le rejet de cet opérateur. Je vote donc pour clore cette question sur la base de l'opinion.

— amon

@amon: J'ai librement admis que ma réponse était de la spéculation au début de mon message. Cependant, j'ai quand même posté une réponse parce que 1. J'enseigne comment pêcher au lieu de donner un poisson, et 2. Ce message peut être utilisé comme cible pour les dupes proches, si nous jouons bien nos cartes. L'idée derrière une réponse fournissant une analyse générale est de décourager les arguments sans fin sur les décisions linguistiques minuscules et d'aider les autres à voir une vision plus large des problèmes globaux.

— Robert Harvey

@RobertHarvey Une cible de dupe canonique «Pourquoi le langage X n'a-t-il pas la fonctionnalité Y» serait-elle pratique, mais la question dans sa forme actuelle ne semble pas convenir à cela. Si elle devait être modifiée pour poser cette question générale (en utilisant X = Java / Y = ?.comme exemple ), elle serait certainement trop large comme une question ordinaire, mais vous auriez une bonne réponse.

— amon

Naturellement, la meilleure personne pour poser cette question est un membre du comité exécutif du JCP, pas nous. Cependant, cela ne m'empêchera pas de me livrer à des spéculations inutiles.

La réponse à chaque question «pourquoi cette fonctionnalité n'a-t-elle pas été implémentée» est-elle toujours parce que les avantages n'ont pas dépassé les coûts.

Eric Lippert (ancien membre de l'équipe C #) dit que, pour qu'un produit ait une fonctionnalité, cette fonctionnalité doit être:

pensé en premier lieu
voulu
conçu
spécifié
mis en œuvre
testé
documenté
expédié aux clients

En d'autres termes, il doit y avoir beaucoup de choses importantes qui doivent se produire avant que toute nouvelle fonctionnalité de langage de programmation puisse être réalisée. Les coûts sont plus importants que vous ne le pensez.

Dans l'équipe C #, chaque nouvelle demande de fonctionnalité commence par un score de moins 100. Ensuite, l'équipe évalue les avantages et les coûts, en ajoutant des points pour les avantages et en soustrayant des points pour les coûts. Si le score ne dépasse pas zéro, la fonctionnalité proposée est rejetée sommairement. En d'autres termes, la nouvelle fonctionnalité doit fournir un avantage convaincant.

Mais l' opérateur Elvis en a fait C #. Alors pourquoi n'a-t-il pas réussi à devenir Java?

Malgré leurs similitudes apparentes, Java et C # ont des philosophies de langage considérablement différentes. Cela est démontré par le fait que les programmes d'entreprise Java ont tendance à être de grandes collections structurelles d'architecture. La brièveté et l'expressivité du langage sont sacrifiées sur l'autel de la cérémonie et la facilité de codage. Les modèles d'architecture logicielle bien connus que tout le monde dans l'équipe de développement peut reconnaître sont préférés aux commodités linguistiques.

Considérez cet échange Reddit :

L'opérateur Elvis a été proposé pour chaque version de Java depuis 7, et a été rejeté à chaque fois. Différents langages se situent sur différents points du spectre, de "purs" à "pragmatiques", et les langages mettant en œuvre l'opérateur Elvis tendent à être plus avancés vers l'extrémité pragmatique du spectre que Java.

Si vous avez une équipe de professionnels Java de plus de 15 ans qui écrivent un système de traitement backend hautement distribué et hautement simultané, vous voudrez probablement une grande rigueur architecturale.

Cependant, si vous avez une équipe de niveau intermédiaire à intermédiaire, dont la moitié a migré de Visual Basic, et que vous leur demandez d'écrire une application Web ASP.NET qui effectue principalement des opérations CRUD ... alors il peut être exagéré de concevoir un groupe de AbstractFactoryFactoryclasses pour éliminer le fait que vous n'avez aucun contrôle sur les colonnes qui peuvent être annulées dans la base de données héritée de merde que vous devez utiliser.

Ces différences profondes dans la philosophie du langage ne concernent pas seulement la façon dont les langues sont utilisées, mais aussi la façon dont le processus de conception du langage lui-même est entrepris. C # est un langage de dictateur bienveillant . Pour intégrer une nouvelle fonctionnalité en C #, il suffit de convaincre une seule personne: Anders Hejlsberg .

Java adopte une approche plus conservatrice. Pour intégrer une nouvelle fonctionnalité à Java, elle doit obtenir le consensus d'un consortium de grands fournisseurs tels que Oracle, IBM, HP, Fujitsu et Red Hat. De toute évidence, ce processus va être plus lent et présenter une barre plus élevée pour les nouvelles fonctionnalités du langage.

La question "pourquoi la fonctionnalité x n'a-t-elle pas été implémentée ..." inclut-elle toujours implicitement les mots "... si c'est évidemment une si bonne idée?" Comme je l'ai suffisamment démontré ici, le choix n'est jamais aussi simple.

— Robert Harvey
source

sarcasme: Parce que les classes AbstractFactoryFactory sont un bon indicateur de la rigueur architecturale, et non du ballonnement du code. /sarcasme.

— Machado

@RobertHarvey Vos conclusions sur le rôle des comités dans la conception du langage Java sont beaucoup trop simplistes. Bien qu'il y ait en effet une collaboration avec la communauté et avec les partenaires de l'industrie, l'affirmation selon laquelle le langage Java est "conçu par un comité" est à peu près complètement incorrecte, et une explication terrible (bien que malheureusement, superficiellement crédible) pour la question de cette affiche.

— Brian Goetz

La plupart des raisons que vous avez énumérées précédemment - chaque fonctionnalité de langue est plus grande que quiconque ne le pense, les budgets finis (pour l'effort, le changement, la complexité) - sont exacts. Et j'ajouterais: nous ne faisons pas la fonctionnalité X parce que nous pensons que d'autres fonctionnalités Y et Z sont de meilleurs choix. De plus, nous adoptons également une approche plus conservatrice que les autres langages, car nous savons que chaque fonctionnalité interagit avec, ou dans certains cas, exclut d'autres fonctionnalités possibles à l'avenir. Nous voulons que Java reste dynamique et pertinent dans 20 ans, ce qui signifie nécessairement de ne pas bourrer toutes les fonctionnalités qui peuvent sembler cool maintenant.

— Brian Goetz

@BrianGoetz: Étant donné que le problème semble être la nature péjorative du terme "conception par comité" (vous remarquerez que je n'ai pas dénigré Java de toute autre manière), j'ai légèrement changé ma réponse pour supprimer le terme.

— Robert Harvey

Il y avait une certaine rivalité entre les concepteurs C # et Java. C # était considéré comme une arnaque par les concepteurs Java (et à juste titre). Les délégués C # ont été rejetés parce qu'ils n'étaient "pas orientés objet", mais la vraie raison était qu'ils sont apparus en C # en premier. Il est agréable de penser que ce n'est que pour des raisons rationnelles que certaines fonctionnalités sont ajoutées ou omises ... J'en doute.

— Frank Hileman