Чому масиви коваріантні, але генеричні дані інваріантні?

З ефективної Java Джошуа Блоха,

1. Масиви відрізняються від загального типу двома важливими способами. Перші масиви є коваріантними. Дженріки інваріантні.

2. Коваріант просто означає, що якщо X є підтипом Y, то X [] також буде підтипом Y []. Масиви є коваріантними, оскільки рядок є підтипом Object So

   String[] is subtype of Object[]

   Інваріант просто означає, незалежно від того, X є підтипом Y чи ні,

    List<X> will not be subType of List<Y>.

Моє питання: чому рішення зробити масиви коваріантними на Java? Є й інші повідомлення SO, наприклад, Чому масиви інваріантні, але списки коваріантні? , але вони, схоже, зосереджені на Скалі, і я не в змозі слідувати.

Через вікіпедію :

Ранні версії Java та C # не включали дженерики (також параметричний поліморфізм).

У таких умовах створення інваріантних масивів виключає корисні поліморфні програми. Наприклад, розгляньте можливість написання функції для переміщення масиву або функції, яка тестує два масиви на рівність, використовуючи Object.equalsметод на елементах. Реалізація не залежить від точного типу елемента, що зберігається в масиві, тому повинна бути можливість записати одну функцію, яка працює на всіх типах масивів. Легко реалізувати функції типу

boolean equalArrays (Object[] a1, Object[] a2);
void shuffleArray(Object[] a);

Однак якщо типи масивів трактуються як інваріантні, можна було б викликати ці функції лише в масиві саме такого типу Object[]. Наприклад, не вдалося перетасувати масив рядків.

Тому і Java, і C # трактують типи масивів коваріантно. Наприклад, в C # string[]є підтипом object[], а в Java String[]- підтипом Object[].

Це дає відповідь на питання : «Чому масиви коваріантного?», Або , точніше, «Чому були масиви з коваріанти в той час ?»

Коли були представлені дженерики, вони цілеспрямовано не ставали коваріантними з причин, на які вказував у цій відповіді Джон Скіт :

Ні, а List<Dog>не є List<Animal>. Поміркуйте, що ви можете зробити з List<Animal>- ви можете додати до нього будь-яку тварину ... включаючи кішку. Тепер ви можете логічно додати кота до посліду цуценят? Абсолютно не.

// Illegal code - because otherwise life would be Bad
List<Dog> dogs = new List<Dog>();
List<Animal> animals = dogs; // Awooga awooga
animals.add(new Cat());
Dog dog = dogs.get(0); // This should be safe, right?

Раптом у вас дуже розгублений кіт.

Оригінальна мотивація для створення масивів коваріантом, описаних у статті вікіпедії, не стосувалася генеричних даних, оскільки символи підказки зробили можливим вираження коваріантності (та противаріантності), наприклад:

boolean equalLists(List<?> l1, List<?> l2);
void shuffleList(List<?> l);

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

Наприклад:

String[] strings = new String[2];
Object[] objects = strings;  // valid, String[] is Object[]
objects[0] = 12; // error, would cause java.lang.ArrayStoreException: java.lang.Integer during runtime

Якщо це було дозволено із загальними колекціями:

List<String> strings = new ArrayList<String>();
List<Object> objects = strings;  // let's say it is valid
objects.add(12);  // invalid, Integer should not be put into List<String> but there is no information during runtime to catch this

Але це спричинить проблеми пізніше, коли хтось спробує отримати доступ до списку:

String first = strings.get(0); // would cause ClassCastException, trying to assign 12 to String

Можливо, це допоможе: -

Генерики не є коваріантними

Масиви на мові Java є коваріантними - це означає, що якщо Integer розширює число (що це робить), то це не тільки Integer також число, але Integer [] також є a Number[], і ви можете вільно пройти або призначити Integer[]де Number[]закликається а. (Більш формально, якщо Number є супертипом Integer, то Number[]це суперпертипом Integer[].) Ви можете подумати, що те саме стосується і загальних типів - List<Number>це супертип List<Integer>, і ви можете передати пропуск, List<Integer>де List<Number>очікується. На жаль, це не працює так.

Виявляється, є вагома причина, що це не працює таким чином: це порушить тип безпеки, який повинні були забезпечити. Уявіть, що ви можете призначити List<Integer>а List<Number>. Тоді наступний код дозволить вам помістити щось таке, що не було цілим числом List<Integer>:

List<Integer> li = new ArrayList<Integer>();
List<Number> ln = li; // illegal
ln.add(new Float(3.1415));

Оскільки ln є a List<Number>, додавання Float до цього видається абсолютно законним. Але якби ln був псевдонім li, то це порушило б обіцянку щодо безпеки типу, що міститься у визначенні li - що це список цілих чисел, і тому загальні типи не можуть бути коваріантними.

Масиви є коваріантними щонайменше з двох причин:

• Це корисно для колекцій, які містять інформацію, яка ніколи не зміниться на коваріантну. Щоб колекція T була коваріантною, її зберігання також має бути коваріантним. Хоча можна було б створити незмінну Tколекцію, яка не використовувала б T[]його сховище резервного копіювання (наприклад, використовуючи дерево або зв'язаний список), така колекція навряд чи зможе виконати так само, як та, яку підтримує масив. Можна стверджувати, що кращим способом забезпечення коваріантних незмінних колекцій було б визначення типу "коваріантного незмінного масиву", яким вони могли б користуватися резервним сховищем, але просто дозволити коваріацію масиву було, мабуть, простіше.

• Масиви часто мутуватимуться кодом, який не знає, який тип речей буде в них, але не вставить у масив нічого, що не було прочитано з того самого масиву. Прекрасним прикладом цього є сортування коду. Концептуально може бути можливим, щоб типи масивів включали методи для заміни або перестановки елементів (такі методи можуть бути однаково застосовні до будь-якого типу масиву) або визначити об'єкт "маніпулятор масиву", який містить посилання на масив та одну чи кілька речей які були прочитані з нього і можуть включати методи збереження раніше прочитаних елементів у масив, з якого вони прийшли. Якби масиви не були коваріантними, код користувача не зміг би визначити такий тип, але час виконання може включати деякі спеціалізовані методи.

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

Важливою особливістю параметричних типів є можливість запису поліморфних алгоритмів, тобто алгоритмів, які працюють на структурі даних незалежно від значення її параметра, наприклад Arrays.sort().

З дженериками це робиться з типовими символами:

<E extends Comparable<E>> void sort(E[]);

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

void sort(Comparable[]);

Однак ця простота відкрила лазівку в системі статичного типу:

String[] strings = {"hello"};
Object[] objects = strings;
objects[0] = 1; // throws ArrayStoreException

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

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

Дженріки інваріантні : від JSL 4.10 :

... Підтипізація не поширюється на загальні типи: T <: U не означає, що C<T><: C<U>...

і кілька рядків далі, JLS також пояснює, що
масиви є коваріантними (перша куля):

4.10.3 Підтипи серед типів масивів

Я думаю, що вони прийняли неправильне рішення в першу чергу, що зробило масив коваріантом. Це порушує безпеку типу, як описано тут, і вони зациклювались на цьому через відсталість сумісності, а потім намагалися не робити тієї самої помилки для загальної. І це одна з причин того, що Джошуа Блох вважає за краще перелічити аргументи в пункті 25 книги "Ефективна Java (друге видання)"

Моє взяття: Коли код очікує масив A [], і ви даєте йому B [], де B є підкласом A, турбуватися можна лише про дві речі: що відбувається, коли ви читаєте елемент масиву, і що станеться, якщо ви пишете це. Тому не важко написати мовні правила, щоб забезпечити збереження безпеки типу у всіх випадках (головне правило полягає в тому, що знак ArrayStoreExceptionможе бути кинутий, якщо ви спробуєте вставити A в B []). Однак для загального, коли ви оголошуєте клас SomeClass<T>, Tв тілі класу може бути використана будь-яка кількість способів , і я здогадуюсь, що це надто складно, щоб виробити всі можливі комбінації, щоб написати правила про те, коли речі дозволені, а коли їх немає.