Um dos recursos propostos para o "Project Coin" do Java 7 foi o "operador Elvis". Um relatório de uma apresentação do JavaOne de 2009 no Project Coin descreveu-o da seguinte forma:
Um dos "pequenos recursos" abordados nesta apresentação é o chamado "operador Elvis", uma versão mais concisa do operador ternário. Percebo que estou perdendo alguns dos recursos do Groovy ao usar o Java tradicional e esse seria um operador que eu poderia usar nas duas linguagens se fosse adicionado. O operador "Elvis" é útil para especificar um valor padrão que pode ser usado quando a expressão avaliada é nula. Como o operador de navegação segura do Groovy, é uma maneira concisa de especificar como evitar nulos desnecessários. Eu escrevi anteriormente sobre como gosto de evitar a NullPointerException.
Enquanto outros aspectos do Project Coin foram finalmente implementados, este não foi. Por que o Elvis Operator foi finalmente rejeitado, apesar de ter sido apresentado no JavaOne como um provável candidato à inclusão?
Para deixar claro, estou perguntando especificamente sobre esse operador e o motivo pelo qual ele foi rejeitado como parte do "Project Coin" do Java 7, já que era considerado seriamente na época. Suspeito que existam listas de discussão ou outras onde os motivos da rejeição foram discutidos, mas não consegui encontrar nada. Se houver informações mais gerais sobre o motivo de não estar incluído em nenhuma versão do Java, isso é aceitável, mas não preferido.
fonte
?.como exemplo ), certamente seria muito ampla como uma pergunta comum, mas você teria uma boa resposta.Respostas:
Naturalmente, a melhor pessoa para fazer esta pergunta é alguém no Comitê Executivo do JCP, não nós. No entanto, isso não me impedirá de me envolver em alguma especulação ociosa.
A resposta para todas as perguntas "por que esse recurso não foi implementado" é sempre porque os benefícios não excederam os custos.
Eric Lippert (ex-membro da equipe de C #) diz que, para que um produto tenha um recurso, esse recurso deve ser:
Em outras palavras, deve haver muitas coisas importantes que devem acontecer antes que qualquer novo recurso da linguagem de programação possa ser realizado. Os custos são maiores do que você pensa que são.
Na equipe de C #, cada nova solicitação de recurso começa com uma pontuação de menos 100. Em seguida, a equipe avalia os benefícios e os custos, adicionando pontos para os benefícios e subtraindo pontos para os custos. Se a pontuação não ultrapassar zero, o recurso proposto será descartado sumariamente. Em outras palavras, o novo recurso deve fornecer um benefício atraente.
Mas o Elvis Operator transformou-o em C #. Então, por que não chegou ao Java?
Apesar de suas aparentes semelhanças, Java e C # têm filosofias de linguagem significativamente diferentes. Isso é evidenciado pelo fato de que os programas corporativos Java tendem a ser grandes coleções estruturais de arquitetura. A brevidade e a expressividade da linguagem são sacrificadas no altar da cerimônia e na facilidade de codificação. Os padrões de arquitetura de software conhecidos que todos na equipe de desenvolvimento podem reconhecer são preferidos às conveniências de linguagem.
Considere esta troca do Reddit :
Essas profundas diferenças na filosofia da linguagem se estendem não apenas à maneira como as línguas são usadas, mas à maneira como o processo de design da linguagem é realizado. C # é uma linguagem ditadora benevolente . Para inserir um novo recurso no C #, você só precisa convencer uma pessoa: Anders Hejlsberg .
Java adota uma abordagem mais conservadora. Para inserir um novo recurso em Java, é necessário obter consenso de um consórcio de grandes fornecedores, como Oracle, IBM, HP, Fujitsu e Red Hat. Obviamente, esse processo será mais lento e apresentará uma barra mais alta para novos recursos de idioma.
A pergunta "por que o recurso x não foi implementado ..." sempre inclui implicitamente as palavras "... se é obviamente uma boa idéia?" Como demonstrei adequadamente aqui, a escolha nunca é tão simples.
fonte