Som du har skrevet din type så skal value kunne assignes til en variabel af en hvilken som helst type. Null er den eneste værdi som har den egenskab...
Nej, lige i dit eksempel kan du godt returnere null fra dit første eksempel, men du kan ikke returnere andet. Din anden stump kode tvinger bare dit type argument til at være samme type som det der returneres. Generics har noget at gøre med typer ikke med klasser så det giver ikke mening at snakke om en class af T.
Jeg vil proeve noget i denne stil (bare uden param Class<T> type): +++ String stringValue = this.get( String.class ); int intValue = this.get( Integer.class ); byte[] byteValue = this.get( byte[].class ); +++ public <T> T get( Class<T> type ) { if ( type.getCanonicalName().equals( "byte[]" ) ) { byte[] returnValue = ... return (T)returnValue; } else if ( ... ) {
Det er ikke java's erasure implementation, du er rendt ind i som arne_v antyder. Du forsøger på at bruge type-inferensen til at give et implicit parameter til en metod, hvilket er en sammenblanding af type-begrebet og klasse-begrebet som slet ikke giver mening i Java-verdenen. Ligemeget hvordan man implementerer generics så er typecheck/type-inferens en compile time ting. Dvs måde med at give en parameter med er den eneste som giver sprogligt mening.
arne_v: Vi kan helt sikkert blive enige om at der er ret stor forskel på C#'s generics og Java's generics. T i C# dækker kun over parameteriserede konkrete typer, mens T i Java er væsentligt mere generel, derfor giver sådan en konstruktion slet ikke mening i Java-sammenhæng. Java's typeinferens kan udover modellen i C# inferere T til at være alt fra forskellige rekursive typer til en delmængde af eksistensielle typer, og i alle de tilfælde giver det ikke mening at have sådan en new() konstruktion, da der ikke findes klasser for disse typer. Når man skriver som ovenstående i C#, så er der altid en klasse svarende til typen og compileren kan give den med som parameter og ved et lille reflection-hack (ved ikke om det er implementeret sådan), så virker det. Derfor giver det mening at have sådan noget i C#, men ikke i Java. Vi er vist udover hvad kernelx spurgte om...
Eksemplet svarer så vidt jeg kan se præcis til hvad spørger efterlyste i spørgsmåls teksten.
Og nej T i C# generics behøver ikke at være en konkret type.
Det gør det naturligvis når man sætter en restriktion på at den skal have en constructor uden argumenter.
Man kunne også godt lave en sådan restriktion i Java.
Men der vil ikke være nogen pointe. new T() kan ikke fungere med type erasure.
Det er netop der forskellen på generics i C# og Java ligger.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.