@darwin: no tak víš jak já sem na tom s psaním knihoven 😉. Já jsem rád, že matlám ty bussines věci nějak aspoň trochu normálně 😉. Ale smysl to dává, né že né 😉
@darwin: "clovek musi propagovat kontext parametr i do tech nejmensich funkci" - neni to spis problem navrhu? funkce, ktere potrebuji kontext jsou docela specialni a mely by byt jen na urcitych mistech a ne rozesete vsude mozne?
@maio: pravda, dost zalezi na typu kodu, ktery clovek pise, samozrejme pri psani pekne pure knihovny ten problem nenastava moc casto, ale pri psani neceho co si potrebuje neustale sahat na nejake resources ten kontext potrebujes predavat vsude, a nebo z neho vybrat co vis ze bude potreba pri volanich nize, ale pak porad rozsirujes parametry i ve funkcich ktere s tim treba nemani nic spolecneho, protoze ten resource budes potrebovat nekde nize
konkretni priklad: chces loggovat pomoci logger “objektu", ne volat jednu a tu samou globalni funkci vsude. co udelas? musis ten logger proste predat i do te nejmensi funkce, ktera si bude chtit neco zalogovat, a to i pres funkce, ktere neloguji a nezajima je to, ale volaji neco co by logovat chtelo
tohle je IMO anti-pattern, logij prostě na stdout/stderr a řeš "Logovací objekt" o úroveň vejš. Takže je to IMO opravdu chyba v návrhu
@rarous: vidis a ja bych rekl, ze stdout a strerr jsou antipatterny, protoze jsou to globalni “resources” na ktere musis implicitne hrabat, kdyz volas logovaci funkci, nekdo “za tebe” rozhodl, ze musis pouzivat log4j a pres to vlak nejede
pattern logovaciho objektu je naprosto v poradku, jen nejde jednoduse v clojure udelat (i jinde)
a btw. reseni “o uroven vejsi” (pomoci bindings
nebo dynamickych globalnich promennych) nefunguje v pripade, za zacnu pouzivat asynchronnin volani (treba core.async), tam se proste bez explicitinho predavani tech veci do funkci neobejdu