Чому операторів Null-Safe (наприклад, «оператор Elvis») було відхилено як частину «Проектної монети» Java 7?


10

Однією із запропонованих функцій для проектної монети Java 7 був "Оператор Елвіса". У звіті з презентації JavaOne 2009 року на Project Coin описано його як таке:

Однією з «дрібних особливостей», висвітлених у цій презентації, є так званий «оператор Елвіса», більш стисла версія потрійного оператора. Я вважаю, що мені не вистачає деяких функцій Groovy при використанні традиційної Java, і це був би один оператор, який я міг би використовувати в обох мовах, якби це було додано. Оператор "Elvis" зручний для визначення значення за замовчуванням, яке може бути використане, коли оцінений вираз є нульовим. Як і безпечний навігаційний оператор Groovy, це стислий спосіб вказати, як уникнути зайвих нулів. Раніше я веду блоги про те, як мені подобається уникати NullPointerException.

Хоча інші аспекти проектної монети в кінцевому рахунку були реалізовані, цього не було. Чому в остаточному підсумку оператор Elvis був відхилений, незважаючи на те, що він був представлений на JavaOne як вірогідний кандидат на включення?

Щоб було зрозуміло, я спеціально розпитую про цього оператора і про причину його відхилення в рамках «Проектної монети» Java 7, враховуючи, що тоді він серйозно розглядався. Я підозрюю, що існують списки розсилки або такі, де обговорювались причини її відхилення, але я нічого не міг знайти. Якщо є більш загальна інформація про те, чому вона не включена в будь-яку версію Java, це прийнятно, але не бажано.


4
підозрілі думки?
Еван

1
Мот, ймовірно, тому, що він підтримує та заохочує використання нулів як законних значень, а ще більш суперечить принципам ОО, оскільки ви перевіряєте тип об'єкта перед виконанням методу.
ЖакБ

Якщо хтось не збирається викопати чіткі документи (електронні листи, записки, стенограми) процесу прийняття рішення або не був безпосереднім учасником рішення, ми не можемо знати відповіді тут. Наприклад, відповідь Роберта - це лише міркування та загальні міркування щодо дизайну мови, а не фактична та конкретна причина відмови від цього оператора. Тому я голосую, щоб закрити це питання на основі думки.
амон

1
@amon: Я вільно визнав, що моя відповідь була спекуляцією на початку мого посту. Однак я все-таки опублікував відповідь, тому що 1. Я вчу, як ловити рибу, а не давати рибу, і 2. Цей пост можна використовувати як ціль для близьких дуп, якщо ми граємо в наші карти правильно. Ідея відповіді, що дає загальний аналіз, полягає в тому, щоб відмовитись від нескінченних аргументів щодо хвилинних мовних рішень та допомогти іншим побачити ширший погляд на загальні проблеми.
Роберт Харві

@RobertHarvey A "Чому мова X не має особливості Y" канонічна ціль дупа була б зручною, але питання в її нинішній формі не здається для цього підходящим. Якби його редагували, щоб задати це загальне запитання (використовуючи X = Java / Y = ?.як приклад ), воно, звичайно, було б занадто широким, як звичайне питання, але у вас буде хороша відповідь.
амон

Відповіді:


15

Звичайно, найкраща людина, яка задає це питання, - це хтось із Виконкому JCP, а не ми. Однак це не завадить мені зайнятися деякими простоюючими спекуляціями.

Відповідь на кожне питання "чому ця функція не була реалізована" завжди є тому, що переваги не перевищували витрат.

Ерік Ліпперт (колишній член команди C #) каже, що для того, щоб продукт мав особливість, ця функція повинна бути:

  • думка в першу чергу
  • бажаний
  • розроблений
  • вказано
  • здійснено
  • перевірений
  • задокументовано
  • відправляється клієнтам

Іншими словами, має бути багато важливих речей, які повинні відбутися до того, як будь-яка нова функція мови програмування може бути реалізована. Витрати більші, ніж ви думаєте.

У команді C # кожен новий запит на функцію починається з оцінки мінус 100. Потім команда оцінює переваги та витрати, додаючи бали за переваги та віднімаючи бали за витрати. Якщо оцінка не перевищує нуля, запропонована функція стисло відкидається. Іншими словами, нова функція повинна забезпечити переконливу перевагу.

Але Оператор Елвіса перетворив його на C #. То чому він не перетворився на Java?

Незважаючи на свою очевидну схожість, Java та C # мають суттєво різні філософії мови. Про це свідчить той факт, що корпоративні програми Java, як правило, представляють собою великі, структурні колекції архітектури. Стислість та мовна виразність приносяться в жертву на вівтарі церемонії та легкості кодування. Відомі програмні схеми архітектури, які кожен із колективу розробників може розпізнати, надають перевагу над мовними зручностями.

Розглянемо цей обмін Reddit :

Оператор Elvis пропонується для кожної версії Java починаючи з 7 і відхиляється кожного разу. Різні мови потрапляють на різні точки спектру від "чистого" до "прагматичного", а мови, що реалізують оператор Елвіса, як правило, знаходяться далі до прагматичного кінця спектру, ніж Java.

Якщо у вас є команда з 15-річних спеціалістів Java, яка пише дуже розповсюджену, дуже одночасну систему обробки резервних копій, то, напевно, ви хочете отримати велику ступінь архітектурної суворості.

Однак якщо у вас є команда молодшого та середнього рівня, половина з яких перейшла з Visual Basic, і ви їх пишете веб-програмою ASP.NET, яка здебільшого просто виконує операції з CRUD ... з AbstractFactoryFactoryкласів абстрагуватися від того факту , що ви не маєте ніякого контролю над якої стовпці обнуляє в дерьмовое успадкованих базах даних, які потрібно використовувати.

Ці глибокі відмінності в мовній філософії поширюються не лише на те, як мови використовуються, але і на спосіб самого дизайну мови. C # - доброзичлива мова диктатора . Щоб отримати нову функцію в C #, вам дійсно потрібно переконати одну людину: Андерса Хейльсберга .

Java застосовує більш консервативний підхід. Щоб отримати нову функцію в Java, вона повинна отримати консенсус від консорціуму великих постачальників, таких як Oracle, IBM, HP, Fujitsu & Red Hat. Очевидно, що цей процес буде протікати повільніше і представлятиме більш високу планку для нових мовних особливостей.

Питання "чому не було реалізовано х функцію ..." завжди неявно включає слова, "... якщо це, очевидно, така гарна ідея?" Як я тут адекватно продемонстрував, вибір ніколи не є таким простим.


8
сарказм: Тому, що класи ClassFactoryFactory є хорошим показником архітектурної строгості, а не здуття коду. / сарказм.
Мачадо

2
@RobertHarvey Ваші висновки щодо ролі комітетів у розробці мови Java занадто спрощені. Хоча справді існує співпраця з громадою та з партнерами по галузі, твердження про те, що мова Java - це "дизайн за комітетом", є майже абсолютно невірним та жахливим (хоч і сумно, поверхово правдоподібним) поясненням цього питання плаката.
Брайан Гец

5
Більшість з перерахованих раніше причин - кожна мовна особливість більша, ніж хтось думає, обмежений бюджет (на зусилля, на зміни, на складність) - точний. І я додам: ми не робимо функцію X, оскільки вважаємо, що інші функції Y і Z - кращий вибір. Крім того, ми також застосовуємо більш консервативний підхід, ніж інші мови, тому що ми знаємо, що кожна функція взаємодіє з іншими, а в деяких випадках, і іншими можливостями в майбутньому. Ми хочемо, щоб Java залишалася яскравою і актуальною протягом 20 років, що обов'язково означає не набивати жодної функції, яка зараз може здатися класною.
Брайан Гец

1
@BrianGoetz: Оскільки проблема, мабуть, полягає в порушаючому характері терміна "дизайн за комітетом" (ви зауважте, що я не зневажав Java будь-яким іншим способом), я трохи змінив свою відповідь, щоб усунути термін.
Роберт Харві

1
Раніше між дизайнерами C # та Java існувало певне суперництво. Дизайнери Java (і це справедливо) вважали, що C # був розмитим. Делегатів C # було відхилено за те, що вони "не орієнтовані на об'єкти", але справжня причина була в тому, що вони з'явилися в C # першими. Приємно думати, що лише з раціональних причин деякі функції додаються чи залишаються поза увагою ... Сумніваюсь.
Френк Хілеман
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.