Fork me on GitHub

@robincarlo84: I've used both friend and buddy and find buddy to be slightly more approachable. Buddy has good docs with examples:


@robincarlo84: When storing a password hash in a database, you'll want to use buddy's hashers:


Hi. Was looking into Om.Next, and think the remote synchronization thing is super interesting. Why write yet another REST server and ajax consumer if it can be automated, and it will, probably, work better and faster! That said, I find Om itself a bit too "frameworkish" (what does synchronization have to do with how I choose to render the content?). Are you aware of any other libraries that try to implement a similar client(cljs) to server (clj) sync system?


Hey, I am not sure exactly how to word this question, but I am curious about the "can't have fixed arity function with more params than variadic function" error. I get what is causing the error but I don't understand the why. Is this a case of an enforced idiom, or is there a lower-level clojure/java reason why this can't/shouldn't be done?


Oh though I guess, if there is just a single argument then & whatever would just consist of a single item so if you did something like a map it would still work fine.


But I am not seeing how you could, for example, use the 1-arity to define the case for a single argument and use variadic to map the 1-arity to a collection


Or, that is, what the obvious alternative is


@igotmine: For your first point, if your fixed-arity part took more arguments than the variadic part, then you essentially have two paths that could take the same number of arguments. Perhaps the rules for disambiguating such a case would have been deemed to be too complex.


Oh of course. Ok, that makes sense.


I was able to get a function to do what I wanted with cons, though it seems a slightly verbose


Between (:key {map}) and ({map} :key) is one preferable or more idiomatic than the other?


@igotmine: it really depends on what you're doing, sometimes one is more clear, sometimes the other


if the keyword is a literal (so not in a variable) I typically put it first


sometimes the map really "feels" like a function


(def name->id
  {:john 7
   :anika 3})

(name->id :john)


functions are maps, it’s just an optimization 😄


contrived example but you see what I mean, it could just as well have been implemented as a function


when both the keyword and the map are vars then sometimes using an explicit get is the way to go


@igotmine: I use the (map :key) form only when map is a lookup table that is known to exist (can't be null) - either in a constant or in a situation where it can be treated like one. a practical reason for that is that it will throw an NPE if the map is null, but I think semantically it reads well too.


I use the (:key map) form when I am treating the :key as an accessor function (which is very common with any kind of "domain entity" / "information structure")


I use get mostly when it would otherwise be unclear what I was doing - for example a lookup on a return value of another function: ((something-that-returns-map) 1234) - I would probably do (get (something-that-returns-map) 1234) to make that more readable.