Чому Java не вводить умовивід?

Мені завжди було цікаво, чому Java не робить умовивід, враховуючи, що мова є такою, якою вона є, і її VM дуже зрілий. Google's Go - це приклад мови з чудовим виведенням тексту, і це зменшує кількість набраних тексту. Чи є якась особлива причина того, що ця функція не є частиною Java?

Технічно кажучи, у Java є типовий інтерес при використанні дженериків. З загальним методом, як

public <T> T foo(T t) {
  return t;
}

Компілятор проаналізує і зрозуміє це, коли ви пишете

// String
foo("bar");
// Integer
foo(new Integer(42));

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

Map<String, String> foo = new HashMap<>();

Java досить люб'язна, щоб заповнити для нас порожні кутові дужки. Тепер чому ж не підтримує підтримку типу Java в рамках змінного призначення? В один момент був RFE для перетворення типів у змінних декларацій, але це було закрито, оскільки "Не виправлять", оскільки

Люди отримують вигоду від надмірності декларації типу двома способами. По-перше, резервний тип слугує цінною документацією - читачам не потрібно шукати декларацію getMap (), щоб дізнатися, який тип вона повертає. По-друге, надмірність дозволяє програмісту оголосити призначений тип і тим самим скористатися перехресною перевіркою, виконаною компілятором.

Доповідач, який закрив це, також зазначив, що він просто відчуває себе "не-java-подібним", з чим я один з цим погоджуватися. Багатослівність Яви може бути і благом, і прокляттям, але це робить мову такою, якою вона є.

Звичайно, що саме RFE не було кінцем цієї розмови. Під час Java 7 ця функція знову була розглянута , і були створені деякі тестові реалізації, зокрема один Джеймс Гослінг. Знову ж таки, ця функція була зрештою знята.

З випуском Java 8 тепер ми отримуємо висновок про тип як частину лямбдів як таких:

List<String> names = Arrays.asList("Tom", "Dick", "Harry");
Collections.sort(names, (first, second) -> first.compareTo(second));

Компілятор Java здатний розглянути метод, Collections#sort(List<T>, Comparator<? super T>)а потім інтерфейс Comparator#compare(T o1, T o2)та визначити, що firstі secondповинно бути, Stringтаким чином, дозволяючи програмісту відмовитися від необхідності перезавантажувати тип у виразі лямбда.

Ну, по-перше, висновок типу не має нічого спільного з терміном виконання часу, незалежно від того, чи буде це 30-річний процесор або VM, який є таким новим, біти все ще блискучі. це все про компілятор.

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

Оновлення: схоже, що java 10 підтримує це - - http://openjdk.java.net/jeps/286

Наскільки мені відомо, коли Java розроблялася на початку дев'яностих років, висновок не був настільки популярний серед основних мов (але це вже була дуже відома концепція, наприклад, в ML). Отже, я можу уявити, що висновок типу, ймовірно, не підтримувався, тому що Java була спрямована на програмістів, що надходять із C ++, Pascal або інших основних мов, які цього не мали (принцип найменшого здивування).

Також одним із принципів проектування Java є чітке написання речей, щоб переконатися, що програміст і компілятор мають однакове розуміння коду: дублювання інформації знижує шанси помилок. Звичайно, може бути питанням смаку, чи варто набрати ще кілька символів додаткової безпеки, яку він забезпечує, але це була філософія дизайну, яку дотримується Java: пишіть речі чітко.

Я не знаю, чи Java отримає висновок про тип у майбутньому, але ІМО, це було б великою революцією для мови (як згадував Гленн Нельсон, вона була описана як "не схожа на java"), і тоді можна також розглянути можливість відкидання назва Java на користь нового імені.

Якщо ви хочете використовувати мову JVM з висновком типу, ви можете використовувати Scala.

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

Це суперечить усталеній рекомендації оголошувати змінні за допомогою найбільш загального інтерфейсу, який відповідає вашим потребам, та ініціалізувати їх відповідним класом реалізації, як у

Collection<String> names = new ArrayList<>();

Ефективно,

var names = new ArrayList<String>();

не що інше, як синтаксичний цукор для

ArrayList<String> names = new ArrayList<String>();

Якщо ви цього хочете, ваш IDE може створити його з new ArrayList<String>()виразу "одним клацанням" (рефактор / створення локальної змінної), але пам’ятайте, що це суперечить рекомендації "використовувати інтерфейси".