Dlaczego Operatorzy Null-Safe (np. „Operator Elvisa”) zostali odrzuceni w ramach „Project Coin” Java 7?

Jedną z proponowanych funkcji „Project Coin” Java 7 był „operator Elvisa”. Raport z prezentacją 2009 JavaOne nad projektem Coin opisał to w następujący sposób:

Jedną z „małych funkcji” omawianych w tej prezentacji jest tak zwany „operator Elvisa”, bardziej zwięzła wersja operatora trójskładnikowego. Czuję, że brakuje mi niektórych funkcji Groovy podczas korzystania z tradycyjnej Java i byłby to jeden operator, którego mógłbym używać w obu językach, gdyby został dodany. Operator „Elvis” jest przydatny do określania wartości domyślnej, której można użyć, gdy obliczone wyrażenie ma wartość NULL. Podobnie jak bezpieczny operator nawigacji Groovy, jest to zwięzły sposób na określenie, jak uniknąć niepotrzebnych zer. Wcześniej blogowałem o tym, jak lubię unikać wyjątku NullPointerException.

Podczas gdy inne aspekty Monety Projektu zostały ostatecznie zaimplementowane, ten nie został. Dlaczego operator Elvis został ostatecznie odrzucony, mimo że został przedstawiony na JavaOne jako prawdopodobny kandydat do włączenia?

Żeby było jasne, pytam konkretnie o tego operatora i powód, dla którego został odrzucony w ramach „Project Coin” Java 7, biorąc pod uwagę, że był wtedy poważnie rozważany. Podejrzewam, że istnieją listy mailingowe lub takie, w których omawiano przyczyny odrzucenia, ale nic nie mogłem znaleźć. Jeśli istnieją bardziej ogólne informacje o tym, dlaczego nie jest on zawarty w żadnej wersji Java, jest to dopuszczalne, ale nie preferowane.

java api-design

— Thunderforge
źródło

podejrzane umysły?

— Ewan,

Mot prawdopodobnie dlatego, że obsługuje i zachęca do używania wartości null jako uzasadnionych wartości, a bardziej zasadniczo jest sprzeczny z zasadami OO, ponieważ sprawdzasz typ obiektu przed wykonaniem metody.

— JacquesB

O ile ktoś nie wykopie wyraźnych dokumentów (e-maile, notatki, transkrypty) procesu decyzyjnego lub nie był bezpośrednim uczestnikiem decyzji, tak naprawdę nie znamy odpowiedzi. Np. Odpowiedź Roberta to tylko spekulacje i ogólne rozważania dotyczące języka, a nie faktyczna i konkretna przyczyna odrzucenia tego operatora. Dlatego głosuję za zamknięciem tego pytania w oparciu o opinie.

— amon

@amon: Przyznaję, że moja odpowiedź była spekulacją na początku mojego postu. Jednak i tak opublikowałem odpowiedź, ponieważ: 1. Uczę, jak łowić ryby zamiast dawać rybę, i 2. Ten post może być wykorzystywany jako cel dla bliskich duplikatów, jeśli dobrze zagramy naszymi kartami. Ideą odpowiedzi stanowiącej ogólną analizę jest zniechęcenie do niekończących się sporów na temat drobnych decyzji językowych i pomoc innym w szerszym spojrzeniu na ogólne problemy.

— Robert Harvey,

@RobertHarvey A Kanoniczny cel dupe „Dlaczego język X nie ma funkcji Y” byłby wygodny, ale pytanie w jego obecnej formie nie wydaje się odpowiednie. Jeśli to miał być edytowany zadać ogólne pytanie (używając X = Y = Java / ?.jako przykład ) z pewnością byłoby zbyt szeroka jak zwykły pytanie, ale czy masz dobrą odpowiedź.

— amon

Oczywiście najlepszą osobą, która może zadać to pytanie, jest ktoś z Komitetu Wykonawczego JCP, a nie my. Nie powstrzyma mnie to jednak od spekulacji.

Odpowiedź na każde pytanie „dlaczego ta funkcja nie została zaimplementowana” zawsze brzmi, ponieważ korzyści nie przekraczały kosztów.

Eric Lippert (były członek zespołu C #) mówi, że aby produkt miał jakąś funkcję, ta funkcja musi być:

pomyślałem w pierwszej kolejności
pożądany
zaprojektowany
określony
zaimplementowano
przetestowany
udokumentowane
wysłane do klientów

Innymi słowy, musi być wiele ważnych rzeczy, które muszą się wydarzyć, zanim będzie można zrealizować jakąkolwiek nową funkcję języka programowania. Koszty są większe, niż myślisz.

W zespole C # każde nowe żądanie funkcji zaczyna się od wyniku minus 100. Następnie zespół ocenia korzyści i koszty, dodając punkty za korzyści i odejmując punkty za koszty. Jeśli wynik nie przekroczy zero, proponowana funkcja zostanie odrzucona. Innymi słowy, nowa funkcja musi zapewniać istotne korzyści.

Ale operator Elvisa dostał się do C #. Dlaczego więc nie przeszedł na Javę?

Pomimo ich widocznych podobieństw, Java i C # mają znacząco różne filozofie językowe. Świadczy o tym fakt, że programy Java dla przedsiębiorstw są zwykle dużymi strukturalnymi kolekcjami architektury. Zwięzłość i ekspresja językowa są poświęcane na ołtarzu ceremonii i łatwości kodowania. Dobrze znane wzorce architektoniczne oprogramowania, które każdy zespół programistów może rozpoznać, są lepsze od udogodnień językowych.

Rozważ tę wymianę Reddit :

Operator Elvisa jest proponowany dla każdej wersji Java od 7 i za każdym razem był odrzucany. Różne języki mieszczą się w różnych punktach spektrum, od „czystego” do „pragmatycznego”, a języki implementujące operatora Elvisa mają tendencję do dalszego zbliżania się do pragmatycznego końca spektrum niż Java.

Jeśli masz zespół ponad 15-letnich profesjonalistów Java, którzy piszą wysoce rozproszony, wysoce współbieżny system przetwarzania zaplecza, prawdopodobnie potrzebujesz dużego stopnia rygorystyczności architektury.

Jeśli jednak masz zespół młodszego i średniego szczebla, z którego połowa przeprowadziła migrację z Visual Basic, i masz ich piszących aplikację sieci Web ASP.NET, która głównie wykonuje operacje CRUD ... wtedy zaprojektowanie grupy może być przesadą z AbstractFactoryFactoryklas abstrakcyjnych away fakt, że nie masz kontroli nad którymi pustych kolumn w bazie gówniany dziedzictwo, które należy wykorzystać.

Te głębokie różnice w filozofii języka obejmują nie tylko sposób, w jaki języki są używane, ale także sposób, w jaki realizowany jest sam proces projektowania języka. C # jest życzliwym językiem dyktatora . Aby uzyskać nową funkcję w języku C #, naprawdę musisz przekonać tylko jedną osobę: Anders Hejlsberg .

Java ma bardziej konserwatywne podejście. Aby uzyskać nową funkcję w Javie, musi uzyskać konsensus od konsorcjum dużych dostawców, takich jak Oracle, IBM, HP, Fujitsu i Red Hat. Oczywiście proces ten będzie wolniejszy i będzie stanowić wyższy pasek dla nowych funkcji językowych.

Pytanie „dlaczego funkcja X nie została zaimplementowana ...” zawsze zawiera niejawnie słowa „… jeśli to oczywiście taki dobry pomysł?” Jak odpowiednio wykazałem tutaj, wybór nigdy nie jest tak prosty.

— Robert Harvey
źródło

sarkazm: Ponieważ klasy AbstractFactoryFactory są dobrym wskaźnikiem rygorystyczności architektury, a nie wzdęcia. /sarkazm.

— Machado,

@RobertHarvey Twoje wnioski na temat roli komitetów w projektowaniu języka Java są zbyt uproszczone. Chociaż rzeczywiście istnieje współpraca ze społecznością i partnerami branżowymi, stwierdzenie, że język Java jest „projektowany przez komisję”, jest całkowicie niepoprawne i jest okropnym (choć niestety, na pozór wiarygodnym) wyjaśnieniem pytania tego autora.

— Brian Goetz,

Większość wcześniejszych powodów, które wymieniłeś - każda funkcja języka jest większa niż ktokolwiek myśli, skończone budżety (na wysiłek, na zmianę, na złożoność) - są dokładne. I dodałbym: nie robimy funkcji X, ponieważ uważamy, że inne funkcje Y i Z są lepszymi wyborami. Ponadto przyjmujemy również bardziej konserwatywne podejście niż inne języki, ponieważ wiemy, że każda funkcja współdziała z innymi możliwymi funkcjami w przyszłości lub w niektórych przypadkach je wyklucza. Chcemy, aby Java pozostała żywa i aktualna za 20 lat, co niekoniecznie oznacza, że nie trzeba wrzucać wszystkich funkcji, które mogą wydawać się teraz fajne.

— Brian Goetz,

@BrianGoetz: Ponieważ problemem wydaje się być pejoratywny charakter terminu „projekt przez komisję” (zauważysz, że nie zlekceważyłem Javy w żaden inny sposób), zmieniłem nieco moją odpowiedź, aby usunąć ten termin.

— Robert Harvey,

Kiedyś była rywalizacja między projektantami C # i Java. C # został uznany za zdzierstwo przez projektantów Java (i słusznie). Delegaci C # zostali odrzuceni za to, że „nie byli zorientowani obiektowo”, ale prawdziwym powodem było to, że pojawili się najpierw w C #. Miło jest myśleć, że tylko z racjonalnych powodów niektóre funkcje zostały dodane lub pominięte ... Wątpię.

— Frank Hileman