Do you have a good tutorial for simple buddy integration?

@leontalbot perhaps https://lambdaisland.com/episodes/buddy-authentication ? - but it's not free. you can still look at the source code: https://github.com/lambdaisland/booklog/tree/ep28-start. 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

oh, ok

(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?

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?

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 clojure.java.jdbc with “com.ibm.as400.access.AS400JDBCDriver” 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

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): 
   ...

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

Thanks for all the feedback! 👍