Anotace @specialized nemusí ušetřit nic, pokud nemáme pole a používáme primitivní typy malého rozsahu (v případě Integeru, tuším, -127 až 127).
Jinak by mě zajímalo, jestli je nějaký problém s tím, že by Scala zmíněný kód zkompilovala zhruba takto:
<code>abstract class X { // hlavně abstraktní metody, které jsou implementovány u potomků }
class X$mcO$sp extends X { var x: Object }
class X$mcI$sp extends X { var x$mcI$sp: Int }
class X$mcD$sp extends X { var x$mcD$sp: Double }</code>
(Chybí mi tu tag pre, snad se to zobrazí dobře.)
Samozřejmě u obou tříd specializovaných na primitivní typ (tj. X$mcI$sp a X$mcD$sp) musí implementovat i metody x()Ljava/lang/Object; a x_$eq(Ljava/lang/Object;)V. Ale to tak jako tak.
Napadají mě jenom dvě věci: interoperabilita s Javou, protože v ní bych musel explicitně psát že chci `X$mcO$sp` místo `X` a pak nejspíš snadnější dědění, které nepotřebuje podporu kompilátoru. V současném schématu je možné, že specializovaná třída má normálního nespecializovaného potomka.
Dědění (aspoň ze Scaly) nebude IMHO velký problém: * V případě nespecializovaného potomka a specializovaného předka se moc nezmění, jen by se muselo dědit z java.lang.Object-ové varianty. Nejspíš žádná velká změna. * Specializované dědění by bylo dokonce čistější. Dnes to při dědění z třídy patrně moc nefunguje (možná je změna od verze 2.10, nevím), dá se narazit na takovouto hlášku: warning: class X must be a trait. Specialized version of class Z will inherit generic X[Double]
Interoperabilita s Javou a případně dalšími jazyky už je zajímavější problém. To by mohl být skutečný důvod, i když asi i to bude nějakými způsoby řešitelné. Například ta obecná implementace přes java.lang.Object by mohla mít speciální jméno, např. X$Generic, což by se v Javě už asi dalo používat dobře. (Dva a více parametrů nevadí, X$Generic by se použilo jen pro případ, že všechny typové parametry jsou kompatibilní s java/lang/Object.) Nebo továrny.
Jinak by mě zajímalo, jestli je nějaký problém s tím, že by Scala zmíněný kód zkompilovala zhruba takto:
<code>abstract class X {
// hlavně abstraktní metody, které jsou implementovány u potomků
}
class X$mcO$sp extends X {
var x: Object
}
class X$mcI$sp extends X {
var x$mcI$sp: Int
}
class X$mcD$sp extends X {
var x$mcD$sp: Double
}</code>
(Chybí mi tu tag pre, snad se to zobrazí dobře.)
Samozřejmě u obou tříd specializovaných na primitivní typ (tj. X$mcI$sp a X$mcD$sp) musí implementovat i metody x()Ljava/lang/Object; a x_$eq(Ljava/lang/Object;)V. Ale to tak jako tak.
* V případě nespecializovaného potomka a specializovaného předka se moc nezmění, jen by se muselo dědit z java.lang.Object-ové varianty. Nejspíš žádná velká změna.
* Specializované dědění by bylo dokonce čistější. Dnes to při dědění z třídy patrně moc nefunguje (možná je změna od verze 2.10, nevím), dá se narazit na takovouto hlášku: warning: class X must be a trait. Specialized version of class Z will inherit generic X[Double]
Interoperabilita s Javou a případně dalšími jazyky už je zajímavější problém. To by mohl být skutečný důvod, i když asi i to bude nějakými způsoby řešitelné. Například ta obecná implementace přes java.lang.Object by mohla mít speciální jméno, např. X$Generic, což by se v Javě už asi dalo používat dobře. (Dva a více parametrů nevadí, X$Generic by se použilo jen pro případ, že všechny typové parametry jsou kompatibilní s java/lang/Object.) Nebo továrny.