strings and ruby style?

Discussion in 'Ruby' started by Kev Jackson, Mar 29, 2006.

  1. Kev Jackson

    Kev Jackson Guest

    Which of the following is considered better style?

    $ie.text_field(args[0],
    $test_data[args[1].to_s]["#{args[2]}_fld"]).value=$test_data[args[1].to_s][args[2].to_s]

    $ie.text_field(args[0],
    $test_data["#{args[1]}"]["#{args[2]}_fld"]).value=$test_data["#{args[1]}"]["#{args[2]}"]

    ie is it better to use args[1].to_s or "#{args[1]}"

    My current thinking is that "#{}" should be used when concatenating
    strings together with values (or interpolating), where as .to_s should
    be used when you want the string representation of an object.

    Thanks
    Kev

    PS - I managed to get rid of all the evals hooray for me!
    Kev Jackson, Mar 29, 2006
    #1
    1. Advertising

  2. Kev Jackson

    Daniel Baird Guest

    ------=_Part_9056_300537.1143607748482
    Content-Type: text/plain; charset=ISO-8859-1
    Content-Transfer-Encoding: quoted-printable
    Content-Disposition: inline

    To my (newbish) eye, it looks crazy to put a single #{} in a string like
    this "#{args[1]}". It looks less crazy to do it when you actually have som=
    e
    literal string content in there as well, like this "#{args[2]}_fld".

    So I guess I'm voting for example one.

    ;Daniel (no, not *that* Daniel)



    On 29/03/06, Kev Jackson <-vn.com> wrote:
    >
    > Which of the following is considered better style?
    >
    > $ie.text_field(args[0],
    >
    > $test_data[args[1].to_s]["#{args[2]}_fld"]).value=3D$test_data[args[1].to=

    _s][args[2].to_s]
    >
    > $ie.text_field(args[0],
    >
    > $test_data["#{args[1]}"]["#{args[2]}_fld"]).value=3D$test_data["#{args[1]=

    }"]["#{args[2]}"]
    >
    > ie is it better to use args[1].to_s or "#{args[1]}"
    >
    > My current thinking is that "#{}" should be used when concatenating
    > strings together with values (or interpolating), where as .to_s should
    > be used when you want the string representation of an object.
    >
    > Thanks
    > Kev
    >
    > PS - I managed to get rid of all the evals hooray for me!
    >
    >



    --
    Daniel Baird
    http://danielbaird.com (TiddlyW;nks! :: Whiteboard Koala :: Blog :: Things
    That Suck)
    [[My webhost uptime is ~ 92%.. if no answer pls call again later!]]

    ------=_Part_9056_300537.1143607748482--
    Daniel Baird, Mar 29, 2006
    #2
    1. Advertising

  3. I like your "current thinking". I also think that the code is easier to
    read if it consistently uses either one approach or the other. This
    rule itself ends up favoring your second example over the first.

    Bret

    ====

    $ie.text_field(args[0],
    $test_data[args[1].to_s]["#{args[2]}_fld"]).value=$test_data[args[1].to_s][args[2].to_s]

    $ie.text_field(args[0],
    $test_data["#{args[1]}"]["#{args[2]}_fld"]).value=$test_data["#{args[1]}"]["#{args[2]}"]
    Bret Pettichord, Mar 29, 2006
    #3
  4. Kev Jackson

    Dave Burt Guest

    Kev Jackson wrote:
    > PS - I managed to get rid of all the evals hooray for me!


    Good work, now just get rid of those "#{fully interpolated}" strings and
    extraneous to_s :)

    > Which of the following is considered better style?
    >
    > $ie.text_field(args[0],
    > $test_data[args[1].to_s]["#{args[2]}_fld"]).value=$test_data[args[1].to_s][args[2].to_s]
    >
    > $ie.text_field(args[0],
    > $test_data["#{args[1]}"]["#{args[2]}_fld"]).value=$test_data["#{args[1]}"]["#{args[2]}"]


    It's nice to fit a line on one line. How's this?

    test = $test_data[args[1]]
    $ie.text_field(args[0], test[args[2] + "_fld"]).value = test[args[2]]

    > ie is it better to use args[1].to_s or "#{args[1]}"


    to_s, but if you control your $test_data and args, and can't imagine how
    args[1] or args[2] could be anything other than strings, there's no need for
    a cast at all.

    > My current thinking is that "#{}" should be used when concatenating
    > strings together with values (or interpolating), where as .to_s should be
    > used when you want the string representation of an object.


    I don't like using interpolation when the stuff I'm interpolating is bigger
    than the literal part of the string.

    Cheers,
    Dave
    Dave Burt, Mar 29, 2006
    #4
  5. Kev Jackson

    Kev Jackson Guest


    >>ie is it better to use args[1].to_s or "#{args[1]}"
    >>
    >>

    >
    >to_s, but if you control your $test_data and args, and can't imagine how
    >args[1] or args[2] could be anything other than strings, there's no need for
    >a cast at all.
    >
    >
    >

    My original goal was to allow the qc team to write

    text :id, :pg_401, :name

    So the arguments in theory should be symbols not strings, hence the need
    for some kind of to_s/#{} hackery

    >>My current thinking is that "#{}" should be used when concatenating
    >>strings together with values (or interpolating), where as .to_s should be
    >>used when you want the string representation of an object.
    >>
    >>

    >
    >I don't like using interpolation when the stuff I'm interpolating is bigger
    >than the literal part of the string.
    >
    >

    However, coming from a Java background, "s1" + "s2" is a performance
    (memory/speed) nightmare, so I shy away from S1 + S2 and try to use
    #{S1}S2 where possible. Perhaps string + string isn't so bad in Ruby,
    but old habits die hard...

    Thanks
    Kev
    Kev Jackson, Mar 29, 2006
    #5
  6. Kev Jackson

    Dave Burt Guest

    Kev Jackson wrote:
    > My original goal was to allow the qc team to write
    >
    > text :id, :pg_401, :name
    >
    > So the arguments in theory should be symbols not strings, hence the need
    > for some kind of to_s/#{} hackery


    That's fair enough, though I'd prefer to either use strings or change the
    $test_data hash to avoid having to convert. For instance, you could use a
    HashWithIndifferentAccess from Rails' Active Support module (require
    'active_support'), or you could just convert the keys to symbols as you load
    the data.

    > ...
    > However, coming from a Java background, "s1" + "s2" is a performance
    > (memory/speed) nightmare, so I shy away from S1 + S2 and try to use
    > #{S1}S2 where possible. Perhaps string + string isn't so bad in Ruby, but
    > old habits die hard...


    It's not so terrible in Java either; when you want to avoid it is where
    you're adding multiple times to get a single result string, especially in a
    big loop. Then you'd use a StringBuffer to avoid creating and
    garbage-collecting zillions of strings. Of course, Ruby's strings are
    mutable, so you don't need another class of object.

    Compare:
    s = ""; 50.times {|i| s += i.to_s + " "} # watch out: 50 strings are
    discarded

    with:
    s = ""; 50.times {|i| s << i.to_s << " " } # like Java's StringBuffer: one
    object, efficient

    Anyway, in this case, "#{x}y" is about the same as x + "y", because you're
    only creating one extra string. You've just got the added method-call
    overhead for String#+.

    > Thanks


    You're welcome.

    Cheers,
    Dave
    Dave Burt, Mar 29, 2006
    #6
  7. Kev Jackson

    Robert Dober Guest

    ------=_Part_543_30243763.1143633139573
    Content-Type: text/plain; charset=ISO-8859-1
    Content-Transfer-Encoding: quoted-printable
    Content-Disposition: inline

    And the winner is....

    -----------------------------------8<--------------------------------------

    626/126 > cat stringperf.rb ; ruby stringperf.rb
    #!/usr/bin/env ruby
    require 'benchmark'

    n =3D 10000
    Benchmark.bm do
    |bm|
    bm.report "String#+ " do
    n.times do
    actual =3D ''
    %w{alpha beta gamma soup}.each do
    |x|
    actual =3D actual + x
    end
    end
    end # do

    bm.report "Interpolation" do
    n.times do
    %w{alpha beta gamma soup}.each do
    |x|
    actual =3D "#{actual}#{x}"
    end
    end
    end # do

    bm.report "Format " do
    n.times do
    %w{alpha beta gamma soup}.each do
    |x|
    actual =3D "%s%s" % [actual, x]
    end
    end
    end
    end # do


    user system total real
    String#+ 0.090000 0.000000 0.090000 ( 0.109451)
    Interpolation 0.150000 0.000000 0.150000 ( 0.153926)
    Format 0.210000 0.000000 0.210000 ( 0.226805)
    -----------------------------------8<--------------------------------------
    Robert

    --
    Deux choses sont infinies : l'univers et la b=EAtise humaine ; en ce qui
    concerne l'univers, je n'en ai pas acquis la certitude absolue.

    - Albert Einstein

    ------=_Part_543_30243763.1143633139573--
    Robert Dober, Mar 29, 2006
    #7
  8. Kev Jackson

    Dave Burt Guest

    Robert Dober wrote:
    > And the winner is....
    > ...
    > String#+ 0.090000 0.000000 0.090000 ( 0.109451)
    > Interpolation 0.150000 0.000000 0.150000 ( 0.153926)
    > Format 0.210000 0.000000 0.210000 ( 0.226805)


    String#+ +1 String
    Interpolate +1 String
    Format +1 String, +1 Array
    String#<< no new objects

    Try this one:

    actual << x

    Cheers,
    Dave
    Dave Burt, Mar 29, 2006
    #8
  9. Kev Jackson

    Robert Dober Guest

    ------=_Part_379_17688623.1143635597208
    Content-Type: text/plain; charset=ISO-8859-1
    Content-Transfer-Encoding: quoted-printable
    Content-Disposition: inline

    On 3/29/06, Dave Burt <> wrote:


    There was a different error I forgot to initialize "actual"


    Dave

    Excellent idea "<<".
    I do not see where there are less objects in << than in +=3D
    actually.
    However << is *the* operator to use. I came up with a benchmark constructin=
    g
    much longer strings
    your << (or concat) is the *best* solution.
    Another approach is not to construct strings immedeatly but to build an
    array and to join the array eventually. For long strings the result is quit=
    e
    speactacular (almost as fast as << )
    Pleas kindly look at this
    -------------------------------9<------------------------------------------
    647/147 > cat string2.rb;ruby string2.rb
    #!/usr/bin/env ruby
    require 'benchmark'

    List =3D %w{ omega delta Ringo } * 50
    n =3D 5000
    Benchmark.bm do
    |bm|
    bm.report "explicit +" do
    n.times do
    actual =3D ''
    List.each do
    |x|
    actual =3D actual + x
    end
    end
    end # do

    bm.report "implicit +" do
    n.times do
    actual =3D ''
    List.each do
    |x|
    actual +=3D x
    end
    end
    end # do

    bm.report "append " do
    n.times do
    actual =3D ''
    List.each do
    |x|
    actual << x
    end
    end
    end
    bm.report "Array " do
    n.times do
    actual =3D []
    List.each do
    |x|
    actual << x
    end
    actual =3D actual.join("")
    end
    end
    end
    user system total real
    explicit + 2.170000 0.010000 2.180000 ( 2.336149)
    implicit + 2.170000 0.010000 2.180000 ( 2.635293)
    append 0.730000 0.000000 0.730000 ( 0.800968)
    Array 0.770000 0.000000 0.770000 ( 0.862098)

    --------------------------------------10<-------------------------------

    Cheers
    Robert


    --
    Deux choses sont infinies : l'univers et la b=EAtise humaine ; en ce qui
    concerne l'univers, je n'en ai pas acquis la certitude absolue.

    - Albert Einstein

    ------=_Part_379_17688623.1143635597208--
    Robert Dober, Mar 29, 2006
    #9
  10. On Mar 28, 2006, at 10:36 PM, Kev Jackson wrote:

    > My current thinking is that "#{}" should be used when concatenating
    > strings together with values (or interpolating), where as .to_s
    > should be used when you want the string representation of an object.


    That sounds right to me.

    James Edward Gray II
    James Edward Gray II, Mar 29, 2006
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kurt Krueckeberg
    Replies:
    2
    Views:
    705
    =?ISO-8859-1?Q?Ney_Andr=E9_de_Mello_Zunino?=
    Nov 17, 2004
  2. Ben

    Strings, Strings and Damned Strings

    Ben, Jun 22, 2006, in forum: C Programming
    Replies:
    14
    Views:
    754
    Malcolm
    Jun 24, 2006
  3. Kza
    Replies:
    4
    Views:
    416
    Andrew Koenig
    Mar 3, 2006
  4. Ken Varn
    Replies:
    0
    Views:
    439
    Ken Varn
    Apr 26, 2004
  5. Mike Semko
    Replies:
    17
    Views:
    1,128
    Old Wolf
    May 7, 2012
Loading...

Share This Page