neco jako node.js pro JVM:

http://vertx.io

LITTLELI: Nehledam, tomu se nedavaji (explicitni) dvojice.

Co me (iracionalne) irituje je, ze ty funkce rikaji "Do tyhle, v mym pripade prazdny mapy nastrkej tyhle (ruznym zpusobem specifikovany) hodnoty a vrat mi vysledek". Co my chybi je funkce, ktera rika "Z tehle hodnot udelej novou mapu". A to navic tak, aby ty hodnoty byly zadany jako vektor dvouprvkovejch (k/v) vektoru.

Ale jak rikam, to je jen moje OCD 8)

a protože jsem slepej, že...
ClojureDocs - clojure.core/assoc-in
http://clojuredocs.org/clojure_core/clojure.core/assoc-in

já sem možná natvrdlej, ale lepší bejt za troubu hned, nehledáš tohle?
ClojureDocs - clojure.core/assoc
http://clojuredocs.org/clojure_core/clojure.core/assoc

LITTLELI: Diky, ale spatne jsem se vyjadril, myslel jsem vylozene funkci v clojure.core, ktera bere (jen) seq of pairs a vraci mapu. Ale taky dobry 8)

REDGUY: zkusim :)

(apply array-map (flatten [[:k1 1] [:k2 2] [:k3 3]]))

Jakej je oficialni zpusob, jak v clojure udelat mapu ze sequence dvouprvkovejch vektoru [key value]?

Delam to (into {} [[:k1 1] [:k2 2] [:k3 3]]), ale prijde mi to takovy osklivy, tim ze tam je ta prazdna mapa na zacatku. Fakt na to neni nejakej dedikovanej "konstruktor", nebo jsem ho jen prehlidl?

(ano, je to prkotina, ale to ze me mluvi moje OCD. Diky za toleranci 8) )

Smalltalk pro JVM:

https://github.com/gravel-st/gravel

Aaaaargh.

Oukej, vzdavam se. Je nejaka mnemotechnicka pomucka, jak si v clojure zapamatovat rozdil mezi (dorun ...) a (doall ...)? Pokazdy to musim jak kokot hledat. Tj. vim jakej ten rozdil je. Jen z hlavy nevim ktera je ktera.

ESORIMMER: Diky, skvelej clanek. Asi to nakonec udelam tak, ze ty funkce budou brat explicitni kontext jako parametr, ale budu je definovat makrem ktery ke kazdy z nich vygeneruje variantu, ktera si ho vezme z nejake vhodne var. Cili se budou volat bude (nejaka-funkce ctx arg1 arg2 ...) nebo (nejaka-funkce* arg1 arg2). Docela se mi libi ta moznost pouzit specialni znak v jmenu funkce jako vizualni indikator ze je necim specificka, je to kratky na psani a pritom zcela prehledny. Navic to makro muze zaroven v ne-hvezdickovy variante generovat pre-assert ze prvni argument je opravdu kontext, aby byla jasna diagnostika kdyz se nekdo prepise... musim rict ze se mi Clojure libi cim dal tim vic 8)

ESORIMMER: reseni 3 se misty pouziva v glibc (printf vs. fprintf, strtok vs. strtok_r, asi dalsi). Clojure neznam, ale tipuju, ze ta bezkontextova funkce se smrskne na jednoradkovy wrapper kolem te hlavni, a s duplikaci kodu v zasade neni problem. Maximalne s duplikaci API.

REDGUY: Osobně bych volil přístup 1. Není to takovej "voser", jak se zdá na první pohled a má to několik výhod: a) je to jednoduchý b) management toho kontextu není v režii knihovny, ale volající aplikace, což může být důležitý c) je to nejvýkonnější řešení d) dobře se to testuje (viz např. ring).

^dynamic pro tyhle účely vypadá lákavě, ale má hromadu "drobných" problémů. Některé zmiňuješ, další čekají za rohem.

řešení 3 vede k tomu, že budeš pálit čas vymýšlením, jak se zbavit duplikace kódu a udržovat všechno (včetně oprav a refaktoringu) aktuální

Pro vysvětlení od povolanějšího můžu doporučit k přečtení tohle (vč. komentářů):

On the Perils of Dynamic Scope | Digital Digressions by Stuart Sierra
http://stuartsierra.com/2013/03/29/perils-of-dynamic-scope

Všecky varianty se tam v zásadě probírají...

ANT_39: Jo, tim usetrim to probublavani skrz svoje funkce. Ale porad budu muset vsude psat (api-function1 *conn* ...), coz je mirnej vopruz, ja bych chtel aby ten 99% pripad byl totalne painless. Zatim mi asi nejlepsi varianta prijde proste pro kazdou funkci mit dve varianty, jednu s a jednu bez explicitniho kontextu (a ta to bude brat z *conn*), coz, jestli chapu spravne defn, by nemel bejt problem...

REDGUY: Nemohl bys udelat (2), s tim, ze tech 99% si ten kontext ulozi do globalni promenne, aby ho nemuseli vsude predavat?

Mam designovej dotaz na pritomne clojuristy. Mirne zjednodusena situace: rekneme ze pisu clojure knihovnu pro komunikaci s nejakym serverem. Ta komunikace neni bezstavova, potrebuju udrzovat nejakej kontext (napriklad autorizacni cookie nebo tak neco), kterej vznika prihlasenim. A rekneme, ze v 99% procentech pripadu programy tu knihovnu budou pouzivat tak, ze se na zacatku prihlasej a celej zbytek behu budou pouzivat tenhle jeden kontext. Nicmene, v 1% bude program potrebovat se s tim serverem bavit pod vice identitama, bud soucasne ve vic threadech, nebo "soucasne" v jednom threadu ale na stridacku.

Kdybych chtel pokrejt jen tech 99%, tak je to jednoduchy. Kontext strcim do nejaky top-level var *connection* a vsechny funkce ty knihovny si ho vezmou odtamtud. Jenomze to nefunguje pro to zbyly jedno procento. Jak to nejlip idiomaticky vyresit?

(1) Proste budu mit funkci (connect username password) ktera mi vrati prislusnej kontext, kterej pak budu strkat do kazdy dalsi funkce te knihovny jako prvni parametr. Coz je strasnej voser, protoze nejen se s tim musim psat, ale musim ho postupne predavat i do vsech svejch funkci aby k nemu mely pristup, atd. A pro tech 99% programu to bude zcela zbytecna prace, protoze to bude porad to samy.

(2) Pouzit top-level var, rekneme *connection*, rict o nem ze je ^:dynamic a v pripade ze potrebuju jinej nez "globalni" kontext, obalit prislusnej kod do (binding [*connection* other-context] ...). Coz mi prislo strasne super, ale pak mi doslo, ze per-thread promene se nededi, takze kdyz bych v ramci toho "binding" zavolal rekneme "pmap" s funkci, ktera by volala moji knihovnu, cely by se to straslive rozbilo protoze thread ze kteryho volam pmap by videl jiny *connection* nez thready vytvorenej pmapem. Coz samozrejme jde resit, ale uplne vidim ty debilni chyby ktery by se blbe hledaly kdyz na to clovek zapomene.

(3) pro kazdou funkci v knihovne mit dve alternativy, jednu s connection parametrem a druhou bez (pouzivajici globalni). Co by slo jednoduse delat makrem, ale prijde mi to trochu osklivy.

Nexistuje nejaky jiny, hezci reseni ktery nevidim? Takovy ktery tech 99% resi trivialne a to zbyly jedno procento je treba i trochu psani navic, ale elegantni a funkcni?