Fork me on GitHub
#hoplon
<
2016-08-30
>
onetom09:08:06

@flyboarder what's the purpose of the let in the config macro? 1. is it just for more concise/uniform reference in the body? 2. is it because evaluation is sequential in lets? 3. there is some other semantic/scoping issue it solves vs using the dynamic vars directly? https://github.com/flyboarder/blaze/blob/master/src/blaze/core.clj#L22-L46

onetom09:08:51

@flyboarder im also trying to run blaze again but it can't find material-hl. i've cloned but it's only version 0.2.0-SNAPSHOT

onetom09:08:19

i see i should do boot develop to increment the minor, but that would still only be 0.3.0-SNAPSHOT so i guess im missing some commits

flyboarder14:08:59

@onetom I'll push a new version of material-hl today, iv fixed a bunch on stuff in it the last few days

flyboarder14:08:08

@onetom: in regards to the let in config, this lets you set up binding and refer to it locally, which lets you use the bindings in things like click handlers and other things which require cross thread access to the bindings

flyboarder14:08:10

I also updated the demo to the latest build: https://blaze-demo-23f77.firebaseapp.com/#

onetom15:08:07

so, if i would just use the dynamic vars in click handlers then it would be possible that by the time i click on it, the binding has already changed?

micha15:08:31

exactly yes

micha15:08:45

just like if the handler runs in another thread

micha15:08:51

which it is actually doing, of course

micha15:08:26

well i guess not precisely, but it acts that way

flyboarder15:08:16

config is just smart sugar around binding

flyboarder16:08:24

You have to think of bindings as a pass over the form, click handlers and things in *-tpl macros have their own pass

onetom16:08:50

i understood what config is, i just cant exactly imagine how the bindings could be changed in a way from outside of the binding block that would affect code within the binding expression. in clojure itself i might be able to imagine since it has real threads, but in js, im not sure it can really happen

flyboarder16:08:42

The main problem I run into is that when code is executed as a callback it usually doesn't have the bindings

micha16:08:15

@onetom dynamic vars are really just global vars in cljs

micha16:08:43

when you do (binding [*foo* 100] (prn *foo*)) what really happens is someting like this:

micha16:08:35

(let [oldfoo *foo*]
  (set! *foo* 100)
  (prn *foo*)
  (set! *foo* oldfoo))

micha16:08:30

now consider this: (def f (binding [*foo* 100] (fn [] *foo*)))

micha16:08:39

what will (f) return?

onetom17:08:14

@flyboarder i can imagine your problematic callback function was referring to a dynamic var, BUT the function itself was created outside of the desired (binding ...) expression

micha17:08:20

(def f
  (let [oldfoo *foo*]
    (set! *foo* 100)
    (fn [] *foo*)
    (set! *foo* oldfoo)))

micha17:08:36

when you call (f) it looks up the value of *foo* at that time

micha17:08:50

and *foo* has already been reset to oldfoo

onetom17:08:57

the value of f won't be that anon-fn in the middle

micha17:08:37

well it's actuially like

flyboarder17:08:42

You'd need to use bound-fn

flyboarder17:08:03

But I like using #

micha17:08:25

(def f
  (let [old *foo*]
    (set! *foo* 100)
    (try
      (fn [] *foo*)
      (finally (set! *foo* old)))))

onetom17:08:25

ok, i think i got it more or less. also looked into the implementation of with-redefs, which is doing what u just showed... i will sleep on it 🙂