Folk tror undertiden, at 'ny T ()' ville være mulig, hvis generiske lægemidler blev reificeret. Det er ikke sandt. Overveje:
klasse Foo {
T f = ny T ();
}
Med sletning implementerer du 'ny T ()' som 'nyt objekt ()', da Objekt er grænsen for T. Med reifikation instantierer du et objekt, hvis klasse er den dynamiske binding for T i 'dette'. Uanset hvad skal du udføre en konstruktør uden argumenter.
Men Foo kræver ikke, at en type bundet til T (alias a vidne af T) har en no-args konstruktør. 'new Foo ()' er helt lovligt, men Integer har ikke en no-args-konstruktør, så hvordan skal instansens initialiseringsudtryk kalde 'new T ()'? Det kan næppe udgøre en standardværdi, der skal overføres til Integer's konstruktør.
'ny T ()' er grundlæggende ikke mulig i sammenhæng med nominel skriv grænser. (Eller hvis du foretrækker det i en sammenhæng med separat kompilering, da en global kompilering kunne beregne, at 'ny T ()' er lyd for alle observerede instantieringer af Foo.) C # 2.0 introducerede en strukturel type bound kaldet den nye () begrænsning for at tillade 'ny T ()'. Imidlertid havde de allerede et behov for interessante regler om, hvilke typer der kan være vidne til en typeparameter, og i den sammenhæng er den "offentlige parameterløse begrænsning" ligetil. C ++ "koncepter" går længere i at tillade en strukturel beskrivelse af de typer, der er i stand til at være vidne til en typeparameter.
Java vil ikke få strukturelle grænser snart. Nominelle grænser af typen C&I (en krydsetype) er komplicerede nok. Derfor kan hverken sletning eller reifikation alene understøtte 'ny T ()'.
Denne historie, "Hvorfor ny T () ikke er mulig i Java", blev oprindeligt udgivet af JavaWorld.
