Perché il compilatore Java non dovrebbe supportare l'ereditarietà delle importazioni?

In Java, le importazioni sono correlate a una classe (esterna), poiché ogni classe (esterna) dovrebbe essere codificata in un file separato. Quindi, si potrebbe affermare che le direttive import ...; prima di una definizione di classe sono associate alla classe (un po 'come le annotazioni sono).Perché il compilatore Java non dovrebbe supportare l'ereditarietà delle importazioni?

Ora, se si potesse ereditare le importazioni di una classe genitore, ciò ridurrebbe notevolmente la confusione dei file sorgente. Perché questo non dovrebbe essere possibile? cioè perché il compilatore Java non dovrebbe considerare anche le importazioni di classi base?

Note:

c'è probabilmente più di una risposta.
So che questo non è un grosso problema se si consente a eclipse di organizzare le importazioni, non c'è bisogno di menzionarlo. Si tratta del "perché", non del "come" (a-la- this).

fonte

2012-12-28 einpoklum

È possibile dichiarare più di una classe in un unico file. Le importazioni sono correlate al file, non a una classe. – MrSmith42

cosa succede se una classe genitore importa 'java.lang.annotation.Annotation' e in una sottoclasse si desidera utilizzare' java.text.Annotation'. Questo sarebbe complicato se le importazioni fossero ereditate. – jlordo

Lascio che il mio IDE gestisca tutte le importazioni e le piega via così non le vedo nemmeno. Trovo che non devo pensarci molto spesso. –

In primo luogo, è importante notare che non ogni classe deve essere codificato in un file separato - ma piuttosto che ogni pubblico, livello superiore classe deve essere. E no, le importazioni non sono realmente associate a nessuna classe - sono solo istruzioni usate per includere determinate classi/pacchetti esterni all'interno di un file in modo che possano essere utilizzati. In realtà, non è necessario importare in realtà nulla, si può sempre utilizzare il nome completo, vale a dire:

java.util.List<String> list = new java.util.ArrayList<String>();

Le importazioni sono per comodità (e solo per il compilatore - sono persi dopo che la classe viene compilato), per evitare di dover scrivere tutto questo e invece di scrivere solo List<String> list = new ArrayList<String> (dopo aver effettuato le importazioni rilevanti da java.util). Di conseguenza, non vi è alcun motivo per cui le sottoclassi debbano "ereditare" le importazioni.

fonte

2012-12-28 19:52:24 arshajii

+1 ogni public, la classe di primo livello deve essere nel proprio file. le classi nidificate pubbliche possono condividere un file. –

+1 e penso sia importante dichiarare esplicitamente che le importazioni ci sono solo per il compilatore (o per facilità di leggibilità per evitare nomi completamente qualificati - qualunque sia la ragione che preferisci). Sono persi dopo che la classe è stata compilata. – cklab

Grazie, fatto questi chiarimenti. – arshajii

Le importazioni sono zucchero sintattico, niente di più. Potresti scrivere qualsiasi programma Java senza mai usare una dichiarazione di importazione se lo volessi davvero. Ad esempio, la seguente classe compila tutto da solo:

class Foo { 
    java.util.List<String> list = new java.util.ArrayList<String>(); 
}

Inoltre, ereditando le importazioni rende molto, molto più difficile da rimuovere un'importazione da una classe. Ad esempio, se Bar.java eredita da Foo.java, potresti non essere in grado di rimuovere un'importazione da Foo senza aggiungerla a Bar. Costringere le importazioni ad essere esplicite rende molto più semplice cambiare un singolo file senza preoccuparsi degli effetti su altri file, che è praticamente un principio fondamentale di programmazione Java e orientata agli oggetti in generale.

(Quest'ultimo punto è legato a questioni che erano a significant factor in the design of Go, che è stato specificamente cercando di evitare i problemi con C e C++ in questo settore.)

fonte

2012-12-28 21:17:58

Quindi, stai dicendo che una rimozione dell'importazione da Foo richiederebbe una ricomposizione di Bar che potrebbe fallire. Ma perché questo è un problema? Lascia fallire e lascia che l'autore di Bar effettui l'importazione stessa. È quello che lui/lei ha bisogno di fare oggi comunque, giusto? – einpoklum

Nello scenario che proponi, Foo importa Baz e Bar importa Foo ma ha anche bisogno di Baz. Se Foo vuole eliminare l'importazione Baz, Bar improvvisamente non ottiene più Baz da Foo, e deve essere riscritto, non solo ricompilato. Questo è il problema. –

Come è un problema? Supponiamo che Bar erediti un metodo da Foo e che la moethod sia rimossa da Foo. Ciò richiederebbe anche una riscrittura. La stessa cosa con l'eredità di Baz di Foo. Una volta associate le importazioni a una classe, ciò diventa ragionevole. A PARER MIO. – einpoklum

Avere ogni file di specificare in modo esplicito le sue importazioni migliora la leggibilità. Immagina di aprire un file e non essere in grado di vedere le dipendenze a colpo d'occhio, perché le importazioni sono ereditate da un altro file.

fonte

2012-12-28 21:24:15

Non ho bisogno di immaginarlo, ce l'ho nella vita reale: nella maggior parte degli altri linguaggi "importa" cose che "importa" altre cose, ad es. includere i file in C e C++. – einpoklum

... e avere 70 importazioni non è davvero una buona leggibilità (a meno che tu non sia il compilatore, ovviamente). – einpoklum

Perché il compilatore Java non dovrebbe supportare l'ereditarietà delle importazioni?

risposta

Problemi correlati