Portál AbcLinuxu, 6. listopadu 2025 17:21
V posledních týdnech se pár chytrých pánů od Javy baví tím, že jak na běžícím pásu generují návrhy specifikace closures pro jazyk Java. Vzhledem k tomu, o jaká jména se jedná, je už celkem jasné, že se closures v Javě 7 dočkáme. Ale v jaké podobě?
Nejdříve dva pojmy, velmi vulgárně a z pozice funkcionálního panice: prvotřídní funkce je funkce, která může být přiřazena do proměnné. Což implikuje pár dalších kouzel: funkce může mít jako návratovou hodnotu funkci. Funkci lze jako parametr předat funkci. Tohle samo o sobě by nebylo příliš zajímavé, všichni jistě známe ukazatel na funkci (moderní onanisté pak řetěz typově bezpečných referencí na metodu), takže co můžeme nabídnout víc?
Closure je prvotřídní funkce, ve které jsou viditelné všechny proměnné, které jsou viditelné v místě její deklarace. To jistě platí i u běžné funkce, jak jsme na ni zvyklí, ale protože ta naše je prvotřídní, můžeme ji ve skutečnosti volat i z míst, kde bychom vůbec neočekávali, že je viditelná. Malý příklad, třeba v JavaScriptu, který se docela dobře čte a je na closures postavený:
function vnejsi() {
var i = 1;
function vnitrni() {
alert(i);
}
return vnitrni;
}
i = -1;
alert(i); // -1
funkce = vnejsi();
funkce(); // 1!!!
Jeden hezký tutoriál na téma closures v JavaScriptu s řadou příkladů najdete na JavaScript Closures for Dummies.
Způsobů využití jsou spousty, zmiňme aspoň dva nejtriviálnější, které určitě přijdou vhod každému programátorovi:
Dáme si jednu drobnou ukázku: řekněme, že chceme v seznamu vyhledat všechna sudá čísla a uložit je do nového seznamu. Příklad je napsaný tentokrát v jazyce Groovy. Srovnejte sami:
cisla = 1 .. 10
// varianta 1., klasická
sudaCisla = []
for (c in cisla) {
if (c % 2 == 0) {
sudaCisla.add(c)
}
}
// varianta 2.
sudaCisla = cisla.findAll {c -> c % 2 == 0}
No, a jak je to konečně s tou Javou? První příklad, ten v JavaScriptu, můžeme v současnosti přepsat použitím anonymní vnitřní třídy:
public class Test {
public interface Funkce {
public void proved();
}
public static Funkce vnejsi() {
final int i = 1;
Funkce vnitrni = new Funkce() {
public void proved() {
System.out.println(i);
}
};
return vnitrni;
}
public static void main(String[] args) {
final int i = -1;
System.out.println(i); // -1
Funkce funkce = vnejsi();
funkce.proved(); // výborně, 1
}
}
Jednu nevýhodu vidíme hned, je jí velmi rozvláčný zápis a nutnost explicitně deklarovat rozhraní. Poměr "syntaktického balastu" a výkonného kódu bývá většinou dost mizerný, ale pro jakous takous "emulaci" prvotřídních funkcí se to použít dá. Jako closure už to ale skřípe: z vnitřní třídy máme přístup jen k těm proměnným, které jsou final (zdráhám se jim říkat konstanty). Takže když do naší JavaScriptové ukázky přidáme jeden řádek:
function vnitrni() {
i++;
alert(i);
}
v Javě už si neškrtneme. Zajímavé je, že původně mělo být možné přistupovat ke všem proměnným vnější třídy, čímž bychom dostali plnohodnotné closures (se strašlivou syntaxí), ale zdá se, že průměrný programátor té doby pro ně ještě nebyl úplně zralý…
Používá se občas jeden hack, jehož podstata je jasně patrná na příkladu s primitivním typem: namísto hodnoty se použije (neměnitelná) reference na ni, typicky jednoprvkové pole. Pole samotné bude final, ale jeho obsah můžeme měnit jak se nám zlíbí:
public static Funkce vnejsi() {
final int[] i = new int[] {1};
Funkce vnitrni = new Funkce() {
public void proved() {
i[0]++;
System.out.println(i[0]);
}
};
return vnitrni;
}
S referenčními typy to pochopitelně funguje úplně stejně, ale celé to je zatraceně zběsilé a nehezké. A protože konkurence nikdy nespí (o čemž jsem se včera sám trapně přesvědčil), pohnuly se ledy i u Sunu. Za přečtení určitě stojí všechny tři zatím existující návrhy Closures for Java od pánů Gilada Brachy, Neala Gaftera, Jamese Goslinga a Petera von der Ahé – 1, 2, 3 –, stejně jako "trucpodnik" Boba Lee, Douga Lea a Joshe Blocha Concise Instance Creation Expressions.
Pěkné je, jak mezi verzemi 0.1 a 0.2 Closures for Java zmizely funkční typy a spolu s tím se výraz function types and inline function-valued expression called closures změnil na delayed-execution blocks of code called closures, ale z komentáře u verze 0.1 mi vyplývá, že jde vlastně o dva paralelní návrhy. Jeden je založený na zařazení funkcí do typového systému jazyka, druhý na využití rozhraní. Z toho je zřejmé, že je ještě velmi brzo na odhady, jak budou v Javě skutečně closures vypadat – já osobně bych dal přednost verzi založené na funkčních typech, ale ani Concise Instance Creation Expressions nakonec nevypadají tak špatně. Horké chvilky asi zažijí návrháři knihoven, které by měly zůstat zpětně kompatibilní a zároveň closures rozumným způsobem podporovat. Prozatím tedy berme výraz prvotřídní Java s jistou rezervou
Omlouvám se všem anglofilům, které pobouřil překlad výrazu first-class function jako prvotřídní funkce. Přeložit closure jako uzávěr jsem si už nedovolil, i když logiku by to mělo jak jazykovou, tak faktickou. Moje skloňování anglických jmen asi taky není úplně nejlepší…
Tiskni
Sdílej:
Od autora úplné reference Common Lispu a spolutvůrce Scheme bych čekal, že nad Javou bude neustále skřípět zuby. 
14.10.2006 20:09
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
new (jedinou výjimkou jsou snad jenom řetězce). Potom se nemůžeš divit, že se představy, tebe jako Smalltalkera a Herona jako Javisty, o tom co je a není objektové, tak zásadně odlišují
14.10.2006 20:39
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Navíc, za pořádek považuji spíše přístup ... všechno je seznam (Lisp), všechno je objekt (Smalltalk). Kdežto v Javě si pořád musím uvědomovat, zda pracuji s číslem, zda s metodou, zda s třídou, anebo s objektem - ne, jednoduchý přístup to opravdu není.
Taky máme zcela jiné představy o eleganci (jak už jsem dávno zjistil ), protože to, co se v Javascriptu napíše na 4 řádky, v Javě vyžaduje rozhraní, anonymní třídy a podobně. Nemůžu si pomoci, ale pro mě je stručnost zápisu (do jisté míry) znakem elegance. Zrovna v případě closures takový Python elegantní není, protože vyžaduje pár řádků navíc, jen k obejití interpreteru.
14.10.2006 21:39
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Taky máme zcela jiné představy o eleganci (jak už jsem dávno zjistil ),
Pravda pravda. Je teda fakt, že syntaxně chudé jazyky jako např. Scheme poněkud na eleganci taky ztrácí . Mě nejde ani tak o stručnost zápisu (vždyť od toho je tu IDE), jako spíš o přehlednost (opět se neshodneme ). Nevím. Píšu trochu jinak, rád mám ve věcech jasno a podobně jako nyní v Javě jsem psal už i v C++ (přesná, dopředu promyšlená hierarchie objektů a jejich důsledné dodržování vs. spoluprogramátoři, kteří mi přenesli C kód, kde využili jeden objekt a říkali tomu program v C++ -- dle mého názoru bastl plný odkazů, pointrů, několika způsobů předávání parametů + nějaké konstrukce pro tvoření tříd apod.).
Ta jednoduchost je dulezita - cim komplikovanejsi konstrukce mi jazyk umoznuje, tim vetsi sance na nasekani chyb je. A nikdo mi to nevymluvi. To mizive procento pripadu, kdy mi to mozna usetri cas kodovani, mi za to nestoji.
Jestlipak vite, kolik chyb naleznete v kodu, ktery je psan C-like jazyku, chyby uplne banalni, ale protoze jazyk to umoznuje a prekladac Vam to neodhali, a to pouziti prirazeni misto porovnani - takovy to jedno krasne zapomenute rovnitko ... kolega ho objevil v kodu, ktery byl prohlasen za plne otestovany a funkcni a nasazeny v produkcnim prostredi. Pak se ptate "proc to tam sakra je?".
Prave me napadl jeste jeden priklad, kdy je jednoduchost lepsi. Vzpomnel jsem si na assembler na proceroech Alpha. Meli jenom par jednoduchych operaci, za to vsechny stejne delky (co do doby zpracovani instrukce) a procesor je tudiz umel zpracovavat "proudove" a paralelismu to take dost pomohlo. x86 procesory maji tunu instrukci provadejici i velmi komplikovane operace, ale nez jsem se takovou instrukci naucil pouzivat, natoz kdyz jsem mel takovy kod po sobe za pul roku precist ... to jsem zase lovil v manualu
Takže Java je jazyk, který Vám nevyhovuje, protože potřebujete IDE, abyste mohl efektivně dělat. IDE je vlastně nadjazyk nad Javou, které Vám doplňuje konstrukce, které Vám v Javě nestačí. Vím, trochu přeháním, ale pokud IDE potřebuje zastírat nedokonalosti jazyka ...
Jestlipak vite, kolik chyb naleznete v kodu, ktery je psan C-like jazyku, chyby uplne banalni, ale protoze jazyk to umoznuje a prekladac Vam to neodhali, a to pouziti prirazeni misto porovnani - takovy to jedno krasne zapomenute rovnitko ... kolega ho objevil v kodu, ktery byl prohlasen za plne otestovany a funkcni a nasazeny v produkcnim prostredi. Pak se ptate "proc to tam sakra je?".
Jestli si myslíte, že v Javě takové rovnítko zapomenout nemůžete jste na omylu. A neznám kód, který by byl bez hromady chyb, byť funkční a nasazený a byl psát v jazyce s jednoduchými konstrukcemi, ať už je to C, Java, Pascal, atd..
Vzpomnel jsem si na assembler na proceroech Alpha. Meli jenom par jednoduchych operaci, za to vsechny stejne delky (co do doby zpracovani instrukce) a procesor je tudiz umel zpracovavat "proudove" a paralelismu to take dost pomohlo. x86 procesory maji tunu instrukci provadejici i velmi komplikovane operace, ale nez jsem se takovou instrukci naucil pouzivat, natoz kdyz jsem mel takovy kod po sobe za pul roku precist ... to jsem zase lovil v manualu
Jenže má to drobnou vadu, Alpha neprorazila. Stejně tak jako LISP, Smalltalk, Simula, a řada pěkných kvalitních jazyků. A namísto toho prorazilo hnusné C, příšerná Java, trochu kvalitnější, atd.. To je holt život, taky mě to štve, ale co nadělám.
Pak to dopadá jako u Ady, kde má frontend překladače půl milionu řádků (GNAT) Je to jasné, jazyky pro kritické aplikace musí co nejvíc možných chyb odchytit už při překladu.
Na druhou stranu existují jazyky, které bych neváhal nazvat brutálně dynamicky typovanými (kde slovo brutálně znamená, že neexistuje principiální rozdíl mezi daty a algoritmy), jejichž počet syntaktických konstrukcí je mnohem menší, ale vyjadřovací schopnosti mnohem větší. (On je to sice stejně všechno Turingáč, ale víme, o čem mluvím.) Takže provádět některá zajímavá kouzla (teď mne napadá třeba runtime modifikace kódu) může být mnohem méně náchylné na chyby právě v nich. Je to samozřejmě proto, že tohle je zase jejich nedílná součást – i když žádnou syntaxi nemá.
Je zřejmé, že intention revealing závisí na rozmanitosti jazyka, a automatické odhalování chyb taktéž. Ale některé věci se prostě líp (a s méně chybami) píšou v jazycích, které něčím takovým nedisponují a disponovat nemohou. Ne že bych to byl někdy dělal, ale myslím, že to tak musí být
Je to jasné, jazyky pro kritické aplikace musí co nejvíc možných chyb odchytit už při překladu.
Jenže Ada se Vám taky snaží pomoct, i když to na první pohled nevypadá. A mnohé věci v Adě miluju, třeba už jen to, že v C/C++, Javě, C# a dalších se plácám s tím, že musím zvolit správný integer správné délky, a občas jiný abych to měl rychlejší, tyhle věci se v Adě neřeší. Prostě řeknu jaké hodnoty tam chci cpát a zbytek je na Adě. Nebo neřeším jestli se proměnná předává hodnotou, nebo odkazem, protože to skoro nikdy řešit nechci. Ada vystihla, že mě zajímá, že chci vědět, jestli je parametr in, nebo out. A podpora multitheadingu a dalších věcí přímo konstrukcemi jazyka je docela blaho oproti tomu, když to musíte mastit na low level os api.
Prostě Ada vystihla, co chce programátor říct a nenutí ho říkat něco jiného. I když je to jazyk složitý, rozvláčný a ukecaný.
Na druhou stranu existují jazyky, které bych neváhal nazvat brutálně dynamicky typovanými
To je ale něco jiného, tam se tyje z toho, že data a kód jedno jsou a bezpečnost je v háji. Na druhé straně jsou to jazyky elegantní, jednoduché, a přitom velmi bohaté co do možností.
14.10.2006 20:34
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Předávání odkazu na funkci je přece jasným "obcházením" objektů. Pravda, neznám žádný návrh, jak by to mělo vypadat v Javě, ale pokud vezmu klasický odkaz na funkci, jak ji známe z C, je pak možné tohle:
Trida1 obj1 = new Trida1 (); Trida2 obj2 = new Trida2 (); obj1.metoda(obj2.jinaMetoda);
A včem je problém: metoda() z obj1 má přístup k jinaMetoda() z obj2 aniž by měla referenci na objekt obj2. Tedy volá metodu nějakého objektu, aniž by měla přístup k danému objektu. Tohle jsem myslel tím neobjektové a na tom trvám. Něco takového tuším umožňují i delegáty v C#.
) liší od rozhraní s jedinou metodou? Tedy kromě toho, že člověk nemusí psát stupidní referenceNaRohraní.Zavolej(parametr), ale napíše jen referenceNaMetodu(parametr), protože u jednometodového rozhraní není co specifikovat. Viz třeba java.awt.event.ActionListener.
Pořád nevím, co na tom je neobjektové, když to podporují Smalltalk, Ruby, Python i další. Smalltalk dokonce zapouzdřuje do objektu i samotné zavolání metody, které se dá odchytit. ^_^ Kromě toho je to docela běžný vzor a osobně mi parametrizace kódu funkcí nebo literálem kódu vyhovuje natolik, že jazyk bez téhle funkce už prostě neberu. (Smalltalk by bez toho ani nefungoval…)
14.10.2006 21:31
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Tak teď to už vůbec nechápu. Čím přesně se ukazatel na členskou funkci (a.k.a. delegát, a.a.k.a. vázaná metoda ) liší od rozhraní s jedinou metodou?
Pozor, ne rozhranní s jedinou metodou (v rozhranní nelze nic implementovat), ale třída. No a liší se právě tím, že místo odkazu na jednu jedinou metodu (tedy vlastně funkci) má k disposici celý objekt. Nemůžu si pomoct, ale přijde mi trochu nesystémové, když se s objektem manipuluje "mimo objekt". Prostě se mi příčí, že někdo bude "jen tak" volat metody, aniž by k tomu objektu měl přístup jako celku. Nevím jestli si rozumíme, už se do těch slovíček trochu zamotávám. Ale myslím, že ten ukázkový kód byl jasný.
Jinak máš pravdu v tom, že pokud se bavíme o třídě implementující pouze jednu metodu tak není větší rozdíl mezi vázanou metodou a touto třídou (nebo anonymní třídou).
Přesně tenhle názor jsem ještě nedávno zastával, ale ona ta parametrizace kódu funkcí je skutečně velmi užitečná. Po pár skriptících v Ruby jsem reference na metody (a hlavně na anonymní metody) definitivně rehabilitoval. Náhrada objektem anonymní třídy je sice možná, ale co mi vadí snad ještě víc než ta hromada zbytečného kódu pro vytvoření instance je nutnost deklarovat extra rozhraní, tohle by se mělo dát udělat na místě použití.
Jen taková poznámka na okraj: dávám přednost tomu slíznout smetanu (tj použít uzávěry v Ruby, při práci s kontejnery), než abych vědomě vymýšlel, kde parametrizovat javovskou metodu metodou.
Já jsem to teď zrovna potřeboval. Pochopitelně jsem mohl mít vedle sebe čtyři metody, každou na dvacet nebo třicet řádek, které by se lišily jedním voláním kdesi uprostřed, ale to jsem radši překousl to rozhraní a anonymní vnitřní třídy. A dal bych přednost tomu, kdybych i v Javě konečně mohl slíznout takovou smetanu. Vývoj Javy dost konzervativní na to, aby to dnešní Javisti, na které ze všech stran útočí RoRýsi, v klidu překousli.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
15.10.2006 23:44