Elegant way to replace a few words in string

[Oleg]

Hello Guys!

I have a string for example "Foo12 Bar130 Qoo20" and map like this
{"Foo" "XF" "Bar" "XB" "Qoo" "XQ}.
I want get: "XF12 XB130 XQ20"

I want to replace words in string based on map association. What is
the elegant way to do it? Sure, i can use loop and recur
to make string enter the next replacement, but is there another way to
do it better?

Cheers, Oleg

[Laurent PETIT]

(reduce
  (fn [#^String s [#^CharSequence what #^CharSequence with]]
    (.replace s what with))
  "Foo12 Bar130 Qoo20"
  {"Foo" "XF" "Bar" "XB" "Qoo" "XQ"})

2010/5/28 Oleg <oleg.r...@gmail.com>

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

[John Cromartie]

I feel like the type hints should be left out until you really need
them, since they kind of clobber the routine's readability.

-John

On May 28, 9:07 am, Laurent PETIT <laurent.pe...@gmail.com> wrote:
> (reduce
>   (fn [#^String s [#^CharSequence what #^CharSequence with]]
>     (.replace s what with))
>   "Foo12 Bar130 Qoo20"
>   {"Foo" "XF" "Bar" "XB" "Qoo" "XQ"})
>

> 2010/5/28 Oleg <oleg.richa...@gmail.com>

>
>
>
> > Hello Guys!
>
> > I have a string for example "Foo12 Bar130 Qoo20" and map like this
> > {"Foo" "XF" "Bar" "XB" "Qoo" "XQ}.
> > I want get: "XF12 XB130 XQ20"
>
> > I want to replace words in string based on map association. What is
> > the elegant way to do it? Sure, i can use loop and recur
> > to make string enter the next replacement, but is there another way to
> > do it better?
>
> > Cheers, Oleg
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clo...@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to

> > clojure+u...@googlegroups.com<clojure%2Bunsu...@googlegroups.com >

[Laurent PETIT]

The rule should really always be: no warning at all (with *warn-on-reflection* set to true, of course).

And in this case, I did what is necessary to avoid reflection warnings. Try it yourself.

2010/5/28 John Cromartie <jcrom...@gmail.com>

[Michael Gardner]

On May 28, 2010, at 12:42 PM, Laurent PETIT wrote:

> The rule should really always be: no warning at all (with *warn-on-reflection* set to true, of course).

I strongly disagree. Why should you care about those sorts of warnings unless you've already identified a bottleneck that needs elimination? IMO the "rule" should be: write it the simplest way you can first, then optimize only what your benchmarks tell you needs optimizing.

[Laurent PETIT]

2010/5/28 Michael Gardner <gard...@gmail.com>

On May 28, 2010, at 12:42 PM, Laurent PETIT wrote:

> The rule should really always be: no warning at all (with *warn-on-reflection* set to true, of course).

I strongly disagree. Why should you care about those sorts of warnings unless you've already identified a bottleneck that needs elimination?

Because in this world of non typed vars and highly generic code, I tend to consider compiler warnings being of similar importance to compiler errors in statically typed languages.
With the additional benefit that since they are warnings, they don't get in your way while you're experimenting and shaping your project's code. But one should consider with care, when commiting code, letting the warnings accumulate "out of control" to the point you're not able to spot the apparition of new ones.
 

IMO the "rule" should be: write it the simplest way you can first, then optimize only what your benchmarks tell you needs optimizing.

Reflection warnings not only reflect potential optimization problems, but also potential bugs, like for the reflection warnings I added in the above example: the String.replace() function is highly overloaded in such a way that if you pass 2 String to it, one function will be taken, but if you explicitly cast the Strings to CharSequences, another implementation (not considering the first string to be a regexp) is taken.

[Laurent PETIT]

2010/5/28 Michael Gardner <gard...@gmail.com>

On May 28, 2010, at 12:42 PM, Laurent PETIT wrote:

> The rule should really always be: no warning at all (with *warn-on-reflection* set to true, of course).

I strongly disagree. Why should you care about those sorts of warnings unless you've already identified a bottleneck that needs elimination?

Said differently than my previous answer : consider removing warnings as the act of keeping your code in a good state/shape. I tend to not get rid of warnings enough in my own java code, but for clojure production code, I would take warnings wayy more  seriously than e.g. java warnings.

My 0,02€,

--
Laurent

[Oleg]

Thank you for great solution.

On 28 май, 23:45, Laurent PETIT <laurent.pe...@gmail.com> wrote:
> 2010/5/28 Michael Gardner <gardne...@gmail.com>

[Dennis]

However, in this case, the point of the code was probably to
show/teach somebody how to solve a problem. When teaching, you want
to make the point as clear as possible, and I think John is trying to
point out, in this instance, the extra code to remove the reflection
warnings detracts from that goal.

I do not disagree with the idea of removing reflection warnings as a
rule and not an exception, especially in production software.

I should probably not fan this fire, but I did anyways... :)

-- Dennis

[Laurent PETIT]

My memory was bad. There's no rampant bug in the code if one does not place type hints. My bad.

2010/5/29 Dennis <shr3...@gmail.com>

[Stuart Halloway]

This is covered in the coding standards doc [1]: "Use type hints for functions that are likely to be on critical code; otherwise keep code simple and hint-free."

Reusable libraries are a strong candidate for type hinting.

[1] http://www.assembla.com/wiki/show/clojure/Clojure_Library_Coding_Standards