Perché le matrici sono covarianti ma i generici sono invarianti?

Da Effective Java di Joshua Bloch,

1. Le matrici differiscono dal tipo generico in due modi importanti. I primi array sono covarianti. I generici sono invarianti.

2. Covariant significa semplicemente che se X è un sottotipo di Y, allora X [] sarà anche un sottotipo di Y []. Le matrici sono covarianti Poiché la stringa è il sottotipo di Object So

   String[] is subtype of Object[]

   Invariante significa semplicemente indipendentemente dal fatto che X sia il sottotipo di Y o no,

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

La mia domanda è: perché la decisione di rendere le matrici covarianti in Java? Esistono altri post SO come Why are Ararys invariant, ma Lists covariant? , ma sembrano concentrarsi sulla Scala e non sono in grado di seguirlo.

Tramite Wikipedia :

Le prime versioni di Java e C # non includevano i generici (noti anche come polimorfismo parametrico).

In tale contesto, rendere invarianti le matrici esclude utili programmi polimorfici. Ad esempio, prendere in considerazione la possibilità di scrivere una funzione per mescolare un array o una funzione che verifica la parità di due array utilizzando il Object.equalsmetodo sugli elementi. L'implementazione non dipende dal tipo esatto di elemento archiviato nell'array, quindi dovrebbe essere possibile scrivere una singola funzione che funzioni su tutti i tipi di array. È facile implementare funzioni di tipo

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

Tuttavia, se i tipi di array fossero trattati come invarianti, sarebbe possibile chiamare queste funzioni su un array esattamente del tipo Object[]. Ad esempio, non è possibile mescolare una serie di stringhe.

Pertanto, sia Java che C # trattano i tipi di array in modo covariante. Ad esempio, in C # string[]è un sottotipo di object[]e in Java String[]è un sottotipo di Object[].

Questo risponde alla domanda "Perché le matrici sono covarianti?", O più precisamente, "Perché le matrici sono state rese covarianti in quel momento ?"

Quando furono introdotti i generici, non furono intenzionalmente resi covarianti per i motivi indicati in questa risposta da Jon Skeet :

No, a List<Dog>non è a List<Animal>. Considera cosa puoi fare con un List<Animal>- puoi aggiungere qualsiasi animale ad esso ... incluso un gatto. Ora, puoi logicamente aggiungere un gatto a una cucciolata di cuccioli? Assolutamente no.

// 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?

All'improvviso hai un gatto molto confuso.

La motivazione originale per rendere le matrici covarianti descritte nell'articolo di Wikipedia non si applicava ai generici perché i caratteri jolly hanno reso possibile l'espressione della covarianza (e della contraddizione), ad esempio:

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

Il motivo è che ogni array conosce il suo tipo di elemento durante il runtime, mentre la raccolta generica non lo fa a causa della cancellazione del tipo.

Per esempio:

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

Se ciò era consentito con raccolte generiche:

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

Ma ciò causerebbe problemi in seguito quando qualcuno tentasse di accedere all'elenco:

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

Potrebbe essere questo aiuto: -

I generici non sono covarianti

Le matrici in linguaggio Java sono covarianti, il che significa che se Integer estende il numero (cosa che fa), allora non solo un numero intero è anche un numero, ma un numero intero [] è anche a Number[], e sei libero di passare o assegnare un Integer[]dove Number[]è richiesto a. (Più formalmente, se Number è un supertipo di Integer, allora Number[]è un supertipo di Integer[].) Potresti pensare che lo stesso valga anche per i tipi generici - che List<Number>è un supertipo di List<Integer>e che puoi passare un punto List<Integer>dove List<Number>è previsto. Sfortunatamente, non funziona in questo modo.

Si scopre che c'è una buona ragione per cui non funziona in questo modo: si spezzerebbe il tipo che i generici di sicurezza dovevano fornire. Immagina di poter assegnare List<Integer>a a List<Number>. Quindi il seguente codice ti permetterebbe di inserire qualcosa che non era un numero intero in un List<Integer>:

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

Perché ln è un List<Number>, l'aggiunta di un float ad esso sembra perfettamente legale. Ma se venissi aliasato li, allora spezzerebbe la promessa di sicurezza del tipo implicita nella definizione di li - che si tratta di un elenco di numeri interi, motivo per cui i tipi generici non possono essere covarianti.

Le matrici sono covarianti per almeno due motivi:

• È utile per le raccolte che contengono informazioni che non cambieranno mai per essere covarianti. Perché una collezione di T sia covariante, anche il suo negozio di supporto deve essere covariante. Mentre si potrebbe progettare una Tcollezione immutabile che non ha utilizzato un T[]archivio di backup (ad esempio utilizzando un albero o un elenco collegato), è improbabile che tale raccolta si comporti come pure quella supportata da un array. Si potrebbe sostenere che un modo migliore per fornire raccolte immutabili covarianti sarebbe stato quello di definire un tipo di "array immutabile covariante" che avrebbero potuto usare un archivio di supporto, ma probabilmente consentire semplicemente la covarianza dell'array era probabilmente più facile.

• Le matrici saranno frequentemente mutate da un codice che non sa che tipo di cosa si troverà in esse, ma non inserirà nell'array tutto ciò che non è stato letto da quello stesso array. Un primo esempio di ciò è il codice di ordinamento. Concettualmente potrebbe essere stato possibile per i tipi di array includere metodi per scambiare o permutare elementi (tali metodi potrebbero essere ugualmente applicabili a qualsiasi tipo di array) o definire un oggetto "manipolatore di array" che contiene un riferimento a un array e una o più cose che era stato letto da esso e che poteva includere metodi per memorizzare elementi già letti nell'array da cui erano venuti. Se le matrici non fossero covarianti, il codice utente non sarebbe in grado di definire tale tipo, ma il runtime avrebbe potuto includere alcuni metodi specializzati.

Il fatto che gli array siano covarianti può essere visto come un brutto hack, ma nella maggior parte dei casi facilita la creazione di codice funzionante.

Una caratteristica importante dei tipi parametrici è la capacità di scrivere algoritmi polimorfici, ovvero algoritmi che operano su una struttura di dati indipendentemente dal suo valore di parametro, come Arrays.sort() .

Con generics, questo viene fatto con i tipi di caratteri jolly:

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

Per essere veramente utili, i tipi di caratteri jolly richiedono l'acquisizione di caratteri jolly e ciò richiede la nozione di un parametro di tipo. Nulla di tutto ciò era disponibile al momento dell'aggiunta di matrici a Java e matrici di tipo covariante di tipo di riferimento consentivano un modo molto più semplice per consentire algoritmi polimorfici:

void sort(Comparable[]);

Tuttavia, quella semplicità ha aperto una lacuna nel sistema di tipo statico:

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

che richiede un controllo di runtime di ogni accesso in scrittura a una matrice di tipo di riferimento.

In breve, l'approccio più nuovo incarnato dai generici rende il sistema di tipi più complesso, ma anche più staticamente sicuro, mentre l'approccio più vecchio era più semplice e meno staticamente sicuro. I progettisti del linguaggio hanno optato per un approccio più semplice, avendo cose più importanti da fare rispetto alla chiusura di una piccola lacuna nel sistema di tipi che raramente causa problemi. Più tardi, quando fu creato Java, e le esigenze urgenti prese in carico, avevano le risorse per farlo nel modo giusto per i generici (ma cambiarlo per array avrebbe rotto i programmi Java esistenti).

I generici sono invarianti : da JSL 4.10 :

... Il sottotipo non si estende attraverso tipi generici: T <: U non implica che C<T><: C<U>...

e qualche riga in più, JLS spiega anche che gli
array sono covarianti (primo proiettile):

4.10.3 Sottotipizzazione tra i tipi di array

Penso che abbiano preso una decisione sbagliata in primo luogo che ha reso l'array covariante. Si rompe la sicurezza del tipo come descritto qui e si sono bloccati a causa della compatibilità con le versioni precedenti e successivamente hanno cercato di non commettere lo stesso errore per i generici. E questo è uno dei motivi per cui Joshua Bloch preferisce gli elenchi agli array nell'articolo 25 del libro "Effective Java (seconda edizione)"

La mia opinione: quando il codice si aspetta un array A [] e tu gli dai B [] dove B è una sottoclasse di A, ci sono solo due cose di cui preoccuparti: cosa succede quando leggi un elemento array e cosa succede se scrivi esso. Quindi non è difficile scrivere regole linguistiche per garantire che la sicurezza dei tipi sia preservata in tutti i casi (la regola principale è che si ArrayStoreExceptionpotrebbe lanciare un an se si tenta di inserire un A in un B []). Per un generico, tuttavia, quando dichiari una classe SomeClass<T>, ci possono essere molti modi in cui Tviene usato nel corpo della classe, e immagino che sia semplicemente troppo complicato elaborare tutte le possibili combinazioni su cui scrivere regole su quando le cose sono permesse e quando non lo sono.