Any alternatives for these two ugly patterns?

2013-05-25 Thread Steven Degutis
There are two patterns I find in my code that I'm still unhappy with but I don't know how to clean up. The first is: (if (:attr obj) obj (assoc obj :attr something)) I'm basically saying, give this hash-map an attribute if it doesn't already have it. And just return the thing with an attribute, r

Re: Any alternatives for these two ugly patterns?

2013-05-25 Thread Jim - FooBar();
On 25/05/13 12:24, Steven Degutis wrote: The first is: (if (:attr obj) obj (assoc obj :attr something)) I'm basically saying, give this hash-map an attribute if it doesn't already have it. And just return the thing with an attribute, regardless if I had to add it or not. (if (contains? obj :

Re: Any alternatives for these two ugly patterns?

2013-05-25 Thread atkaaz
may I see the macro for the latter, if you decide to go that way ? thx On Sat, May 25, 2013 at 2:24 PM, Steven Degutis wrote: > There are two patterns I find in my code that I'm still unhappy with but I > don't know how to clean up. > > The first is: (if (:attr obj) obj (assoc obj :attr somethi

Re: Any alternatives for these two ugly patterns?

2013-05-25 Thread Jim - FooBar();
no need for macros... :) (definline safe-assoc [m k v] `(if (contains? ~m ~k) ~m (assoc ~m ~k ~v))) (definline pred-transform [obj pred tf] `(if ~(pred obj) ~obj ~(tf obj))) Jim On 25/05/13 12:44, atkaaz wrote: may I see the macro for the latter, if you decide to go that way ? thx On

Re: Any alternatives for these two ugly patterns?

2013-05-25 Thread atkaaz
didn't know about definline, thanks Jim! On Sat, May 25, 2013 at 2:51 PM, Jim - FooBar(); wrote: > no need for macros... :) > > (definline safe-assoc [m k v] > `(if (contains? ~m ~k) ~m > (assoc ~m ~k ~v))) > > (definline pred-transform [obj pred tf] > `(if ~(pred obj) ~obj > ~(tf obj)))

Re: Any alternatives for these two ugly patterns?

2013-05-25 Thread atkaaz
just wondering if obj is a form does it get evaluated twice? On Sat, May 25, 2013 at 2:51 PM, Jim - FooBar(); wrote: > no need for macros... :) > > (definline safe-assoc [m k v] > `(if (contains? ~m ~k) ~m > (assoc ~m ~k ~v))) > > (definline pred-transform [obj pred tf] > `(if ~(pred obj) ~ob

Re: Any alternatives for these two ugly patterns?

2013-05-25 Thread atkaaz
Shouldn't it be like: (definline pred-transform [obj pred tf] `(if (~pred ~obj) ~obj (~tf ~obj))) => (pred-transform 1 #(not (nil? %)) println) 1 => (pred-transform 1 nil? println) 1 nil On Sat, May 25, 2013 at 2:55 PM, atkaaz wrote: > just wondering if obj is a form does it get eva

Re: Any alternatives for these two ugly patterns?

2013-05-25 Thread atkaaz
in which case it does get evaluated twice if form: => (pred-transform (println 1) #(not (nil? %)) #(println % ".")) 1 1 nil . nil => (pred-transform (println 1) nil? #(println % ".")) 1 1 nil so maybe a let + gensym would be in order? On Sat, May 25, 2013 at 3:04 PM, atkaaz wrote: > Shouldn'

Re: Any alternatives for these two ugly patterns?

2013-05-25 Thread atkaaz
like: => (definline pred-transform [obj pred tf] `(let [o# ~obj] (if (~pred o#) o# (~tf o# #'cgws.notcore/pred-transform => (pred-transform (println 1) nil? #(println % ".")) 1 nil => (pred-transform (println 1) #(not (nil? %)) #(println % ".")) 1 nil . nil On Sat, May 25, 201

Re: Any alternatives for these two ugly patterns?

2013-05-25 Thread atkaaz
I wonder why the definline didn't act like a function? => (defn pred-transform [obj pred tf] (if (pred obj) obj (tf obj))) #'cgws.notcore/pred-transform => (pred-transform (println 1) #(not (nil? %)) #(println % ".")) 1 nil . nil => (pred-transform (println 1) nil? #(println % ".")) 1 n

Re: Any alternatives for these two ugly patterns?

2013-05-25 Thread Cedric Greevey
Seems to me that (merge {:attr something} obj) answers the OP's question, mentions obj only once, and is short and pithy. OTOH it computes the "something" every time, whether it's needed or not, so in cases where "something" is expensive to compute (or has side effects that should only happen if it

Re: Any alternatives for these two ugly patterns?

2013-05-25 Thread Steven Degutis
Thanks, that solution's pretty great, although you're right about the side-effects problem, so I can't always use this solution. Also I just remembered, sometimes to solve the second one, I would do ((if condition transformer identity) obj) but that feels ugly. On Sat, May 25, 2013 at 7:13 AM, C

Re: Any alternatives for these two ugly patterns?

2013-05-25 Thread atkaaz
On Sat, May 25, 2013 at 3:16 PM, Steven Degutis wrote: > > Also I just remembered, sometimes to solve the second one, I would do ((if > condition transformer identity) obj) but that feels ugly. > but the condition has to contain obj, so obj is referred twice ? otherwise i kinda like it > > > On

Re: Any alternatives for these two ugly patterns?

2013-05-25 Thread Chris Ford
Here's how I did it, which is similar to what atkaaz and Jim were suggesting: (defn whenever [x applies-to? f] (if (applies-to? x) (f x) x)) (whenever obj :attr #(assoc % :attr something)) (whenever obj some-test some-transformation) On 25 May 2013 15:19, atkaaz wrote: > > > > On Sat, May 25,

Re: Any alternatives for these two ugly patterns?

2013-05-25 Thread Cedric Greevey
If the condition is true of the transformed object (e.g., it's "if this condition isn't met, use this method to massage it so it is"), then there's this: (first (filter condition? (map #(%1 obj) [identity transformation]))) It can even use laziness to avoid the transformation, but you'll need (li

Re: Any alternatives for these two ugly patterns?

2013-05-25 Thread Matching Socks
(update-in obj [:attr] #(or %1 %2) something) (cond-> obj (not (:attr obj)) (assoc :attr something)) -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members

Re: Any alternatives for these two ugly patterns?

2013-05-25 Thread Steven Degutis
Seems like I almost want arbitrary or-like behavior, like only-sometimes-evaluation of a conditional form. I feel like this could have something to do with lazy sequences, since technically has the option of never getting evaluated. We could use map. Will test some things out in nrepl.el and retu

Re: Any alternatives for these two ugly patterns?

2013-05-25 Thread Jim - FooBar();
so maybe a let + gensym would be in order? yes that is what you do to avoid double-evaluation...:) I was making a different point though, the fact that definline produces a first class fn which still expands like a macro. Jim -- -- You received this message because you are subscribed to t

Re: Any alternatives for these two ugly patterns?

2013-05-25 Thread atkaaz
yep that was interesting thanks btw; it was a function that was acting like a macro, how odd On Sat, May 25, 2013 at 4:26 PM, Jim - FooBar(); wrote: > so maybe a let + gensym would be in order? >> > > > yes that is what you do to avoid double-evaluation...:) I was making a > different point thou

Re: Any alternatives for these two ugly patterns?

2013-05-25 Thread Kelker Ryan
Here's my solution to your problem. Let me know if it helps. ``` user> (defn if-attr [-key obj missing] (if-let [ret (get obj -key)] ret (assoc obj -key missing))) #'user/if-attr user> (if-attr :abc {} "missing-value") {:abc "missing-value"} user> (if-attr :abc {:abc 123} "missing-value") 1

Re: Any alternatives for these two ugly patterns?

2013-05-25 Thread Jim - FooBar();
I just realised you can also do this to get the same effect of pred-transform...This is the first time I'm using cond->! I'm starting to realise its usefuleness... :) (let [rpred (complement pred)] (cond-> obj (pred obj) identity ;;if true return it untouched (rpred obj) t

Re: Any alternatives for these two ugly patterns?

2013-05-25 Thread Steven Degutis
Another solution, repeats itself slightly less: (assoc obj :key (or (:key obj) (something-else-with-side-effects-maybe?))) Not sure I like it much better than the first one. But I usually prefer not writing my own macros/functions when I can avoid it, so it has that plus. On Sat, M

Re: Any alternatives for these two ugly patterns?

2013-05-26 Thread dmirylenka
> > (merge {:attr something} obj) -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscr

Re: Any alternatives for these two ugly patterns?

2013-05-26 Thread dmirylenka
Sorry, that's just another suggestion for the first pattern. For the second, I would use: (cond-> obj (some-test obj) some-transformation) On Sunday, May 26, 2013 12:05:49 PM UTC+2, dmirylenka wrote: > > (merge {:attr something} obj) > > -- -- You received this message because you are subscri