@5: "final je po technicke strance v Jave zbytecne". Ne tak uplne, nutnost mit promennou jako final je dusledek implementace, protoze Java ve skutecnosti hodnoty vsech nelokalnich promennych kopiruje do vnitrni funkce - JVM samotna nema prostedky jak pristupovat do jineho nez aktualniho framu. final je tedy jen "pojistka" aby bylo bezpecne hodnotu kopirovat.
"protoze ramec muze byt bez ujmy na obecnosti alokovany na heapu a jde to diky lexikalnimu rozsahu platnosti zjistit behem prekladu a neni potreba nejake kopirovani."
Teoreticky ano, prakticky to neni tak snadne. Moderni CPU konstruovana pro vykonavani klasickeho Ccka, kde vsechny framy jsou na stacku. Pokud chci rychly kod, frames se musi alokovat na stacku - nebo to alespon hoodne pomuze, JIT tvori kod velmi podobny C kodu. Alokovat neco na heapu, neco na stacku by JIT hodne seslozitilo. Navic, statisticky velmi malo framu prezije svuj vlastni navrat, takze vykonne VM alokuji vsechny framy na stacku a na heap se kopiruji jen pokud je frame referencovat po svem navratu. Toto reseni dava statisticky obecne lepsi vysledky.
CLR rovnez nema primou podporu pro pristup do nelokalniho framu a lambdy resi stejne jako navrhuje @7 (coz je princip tzv Closure Compileru pro novejsi verze SqueakVM/CogVM). Toto sice funguje, na druhou stranu se jedna o jisty "podvod", nebot za cenu jednodussi implementace VM se plati vyssim vypocetnim casem (pole se alokuje, coz nese mnohem vetsi rezii nez alokace na stacku navic tato alokace se provadi vzdy, nezavisle na tom, jestli frame prezije nebo neprezije svuj navrat)
ČLÁNKY DO MAILU