This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-06-20
Channels
- # aws (1)
- # babashka (68)
- # beginners (68)
- # braveandtrue (6)
- # calva (4)
- # cider (10)
- # clj-kondo (26)
- # clojure (76)
- # clojure-dev (18)
- # clojure-europe (1)
- # clojure-norway (25)
- # clojure-spec (8)
- # clojure-sweden (7)
- # clojure-uk (3)
- # clojuredesign-podcast (1)
- # clojurescript (11)
- # conjure (29)
- # cursive (31)
- # datomic (29)
- # emacs (12)
- # fulcro (29)
- # graphql (3)
- # helix (2)
- # hoplon (39)
- # hugsql (4)
- # malli (3)
- # off-topic (62)
- # pedestal (8)
- # re-frame (23)
- # reagent (14)
- # rewrite-clj (10)
- # shadow-cljs (18)
- # spacemacs (3)
- # sql (13)
- # xtdb (32)
Jeg skrev en kommentar til @magnars vedr hans threading post. Han ha’kke kommentert på den, så jeg tar sjansen på å legge den her: Hey! Bra blogpost om threading. En ting som jeg synes threading hjelper veldig med er at man unngår dype call-stacks på godt og vondt. Jeg har ikke helt klart å formulere dette ordentlig, men i java er det jo ikke uvanlig å skrive kode som dette (som jeg skriver i Clojure :):
(defn d [...] )
(defn c [...]
...
(d ...))
(defn b [...]
...
(c ...))
(defn a [...]
...
(b ...))
Hei! Hvor kan jeg se posten hans? Takk!
Ikke meninga å være dust og ikke svare. Denne dukket ikke opp for meg før Clojurians fikk seg Slack-historikk. 🙂
No worries :)
Dette er ofte et resultat av "extract method". Problemet her er at alt er like tett koblet som det en gang var, og det er vanskelig å leke med ting i isolasjon. Threading hjelper deg til å skrive dette på en mer funksjonell måte:
(->> a b c d)
Sånn ca.:thinking_face: :thinking_face: :thinking_face: :thinking_face: blir ikke call stacken like dyp? :thinking_face: :thinking_face:
(f (g (h (i))))
har til enhver tid bare en funksjon på stacken (sånn jeg forstår det) fordi du lar i
gjøre seg ferdig før du kaller h
som må få gjøre seg ferdig før du kaller g
osv.
Der du kaller fra en "tail" posisjon over kunne man sikkert gjort sånn som man gjør med tco, nemlig bytte ut hele stack -framen med det som skal til for å invokere funksjonen i tail-posisjon, men det kan man jo ikke gjøre på jvm'en i allefall.
hmmm ja, det er jo et poeng, mens i den andre er det tail calls, og jvm-en har ikke tco, riktig
Nå er det egentlig ikke de dype call-stackene jeg ikke liker, men heller det at koden er "koblet" selvom vi har ekstrahert funksjonenen.
Jo, du må ha returverdien på stacken, men i det første eksemplet har du 4 stackframes kjørende. Det har du ikke i det andre eksemplet.
(tror jeg). Dette er jo langt over mitt inkompetansenivå, selvom jeg tok IN140 en gang tidlig på nittitallet.
ja, for de smarte datamaskinene være tar vel bare returverdien til i og gjør om til inputverdien til h, får man tro
ordet "calling conventions" havnet i hodet mitt, er vel masse detaljer rundt akkurat hvordan de gjør det. Men de trenger jo ikke å ta vare på eventuelel input-verdier til i og andre funksjonskall som har skjedd inni i, osv
I det første eksemplet kan man ikke kalle a
uten å også kalle b
, c
, og d
(uten å bedrive mocking/redeffing
I det andre eksempet er kan man lett kalle a
i isolasjon, noe som er nice mhp tester.