Fork me on GitHub

Do you have a good tutorial for simple buddy integration?


@leontalbot perhaps ? - but it's not free. you can still look at the source code: However, if you're interested in more than one episode consider subscribing - it's really worth it.


Saw it, thanks! It uses component. Was curious about a ring integration


it’s not possible to use buddy without ring as far as I know


component and ring do completely different things, and are often used together


(Testing in CLJS 1.9.542), I get an error "could not find tag parser for :user ..." trying (cljs.reader/read-string "#:user{:a 1 :b 2}"). What is the correct way to read a namespaced map?

Alex Miller (Clojure team)16:05:34

Seems like CLJS 1.9.542 should know how to read namespaced maps, shouldn’t it? I thought that was added a while ago.


#:user{:a 1 :b 2} does work just fine.


Do I need to wrap some binding, or use something other than cljs.reader/read-string?

Alex Miller (Clojure team)16:05:17

not sure. tools.reader, which the cljs reader uses supports namespaced maps. I’m not clued in enough to know the difference between that and cljs.reader/read-string.


So I have a db query that returns me a keyword :ov@@prev When I filter with that, it gives me symbol prev unknown error. Is there an escape char or the like to make it work, or do I need to rename my result?


@fingertoe I prefer to not keywordize, but you can just use (keyword "ov@@prev") also


it’s not a valid keyword according to the reader rules, but you can make a keyword out of anything that can fit in a string (for better or worse)


it might be that it’s cumbersome to turn off the keywordizing (depending on your db library) but I recommend just not turning random garbage into keywords in the first place


I am using with “” Not sure how to turn that keywordize switch on or off.. The (keyword “ov@@prev”) does make my filter work.


I’d suppose the right answer is to Select as and give it a keyword that is legit.


that would work too - I’m surprised there’s no easy way to just get the keys as strings

Drew Verlee19:05:56

Random question of the day. When does it make sense to not use a single hashmap as the argument to your function. It seems like the typical thing to do in most languages is to expect an ordered list of arguments.

def full-name(first , last): 
but do we really care about the order? When would using a list be better then a hashmap with validation checks?


great question. for me list vs hashmap is about extensibility. If you choose a list, and make a change where you need to require more arguments, now you have to change every single calling signature. Hashmaps are associative and represent an open information model... you can just add a key and choose to use it or not.


and makes the default values super simple. in c# this is nice but requires a language feature. Method(arg3: val3, arg2: val2) vs (method {:arg3 val3 :arg2 val2})


ah but a reason to not use a map is so that you can use apply easily with it


I can only think of two cases where an ordered list is better: 1) when efficiency really matters. (and these cases are increasingly rare; and I'd imagine that any half-decent compiler can optimize most real cases anyway). 2) when the function is so simple that the mental overhead of typing/reading the argument keywords is greater than the flexibility that they give.


If there is a set of required args, I will always want to see them as explicit args, in order from the most general to least general, or least variable to most variable


but the clojure compiler doesn’t do those kinds of optimizations


And then there are obvious cases: can't imagine map taking {fn: #(inc %) :coll [1 2 3]} or addition taking a map of things to add rather than just a list


just to point out the simple case to "when does it make sense to not use a single hashmap as the argument to your function".


yeah, it breaks things like threading, apply, map, reduce, etc.


you lose a lot of the functional-y syntax tricks

Drew Verlee20:05:59

Thanks for all the feedback! 👍