Защо нов T () не е възможен в Java

Хората понякога мислят, че „ново T ()“ би било възможно, ако генеричните лекарства бяха преифицирани. Това не е истина. Обмисли:

клас Foo {

T f = ново T ();

}

С изтриване, вие реализирате 'new T ()' като 'new Object ()', тъй като Object е границата на T. С реификация, вие създавате екземпляр на обект, чийто клас е динамичното обвързване за T в 'this'. Така или иначе, трябва да изпълните конструктор no-args.

Но Foo не изисква тип, свързан с T (известен още като свидетел на T), да има конструктор no-args. 'new Foo ()' е напълно легален, но Integer няма конструктор no-args, така че как изразът за инициализация на екземпляра трябва да извиква 'new T ()'? Едва ли може да измисли стойност по подразбиране, която да се предаде на конструктора на Integer.

„new T ()“ по принцип не е възможно в контекста на номиналните граници на типа. (Или, ако предпочитате, в контекста на отделна компилация, тъй като глобалната компилация може да изчисли, че „new T ()“ е звук за всички наблюдавани инстанции на Foo.) C # 2.0 въведе структурен тип, обвързан с ограничението new () за да разрешите „нов T ()“. Те обаче вече имаха нужда от интересни правила за това кои типове могат да станат свидетели на параметър на типа и в този контекст „публичното ограничение без параметри“ е ясно. "Концепциите" на C ++ отиват по-далеч, като позволяват структурно описание на типовете, способни да станат свидетели на параметър тип.

Java скоро няма да получи граници на структурен тип. Границите на номиналния тип на формата C&I (тип пресичане) са достатъчно сложни. Следователно нито изтриването, нито повторното преобразуване само по себе си могат да поддържат „нов T ()“.

Тази история „Защо новият T () не е възможен в Java“ е първоначално публикувана от JavaWorld.