destructive! operations

Discussion in 'Ruby' started by Navindra Umanee, Feb 20, 2005.

  1. Hi,

    Is it more efficient to use the destructive versions of functions in
    Ruby? I know that in Lisp/Scheme destructive counterparts are usually
    offered for efficiency reasons.

    Can I assume that string.gsub! is preferable to string.gsub when I
    know that the side-effect won't be affecting any other code?

    I find the Ruby destructive operations sometimes inconvenient to use.
    For example strip! might return null where strip would return a
    string. However, if it's more efficient, I'd rather use the
    destructive version.

    Thanks,
    Navin.
    Navindra Umanee, Feb 20, 2005
    #1
    1. Advertising

  2. Hi

    In message "Re: destructive! operations"
    on Sun, 20 Feb 2005 17:22:34 +0900, Navindra Umanee <> writes:

    |Is it more efficient to use the destructive versions of functions in
    |Ruby? I know that in Lisp/Scheme destructive counterparts are usually
    |offered for efficiency reasons.
    |
    |Can I assume that string.gsub! is preferable to string.gsub when I
    |know that the side-effect won't be affecting any other code?

    Although most (not all) of bang methods are more efficient than their
    counterparts, I discourage the use of them unless the performance is
    really problem. "Premature optimization is the source of all evil".

    matz.
    Yukihiro Matsumoto, Feb 20, 2005
    #2
    1. Advertising

  3. "Yukihiro Matsumoto" <> schrieb im Newsbeitrag
    news:...
    > Hi
    >
    > In message "Re: destructive! operations"
    > on Sun, 20 Feb 2005 17:22:34 +0900, Navindra Umanee
    > <> writes:
    >
    > |Is it more efficient to use the destructive versions of functions in
    > |Ruby? I know that in Lisp/Scheme destructive counterparts are usually
    > |offered for efficiency reasons.
    > |
    > |Can I assume that string.gsub! is preferable to string.gsub when I
    > |know that the side-effect won't be affecting any other code?
    >
    > Although most (not all) of bang methods are more efficient than their
    > counterparts, I discourage the use of them unless the performance is
    > really problem. "Premature optimization is the source of all evil".


    Although I agree to the latter statement, I beg to differ on the general
    remark - at least a bit. I often use this

    while ( line = gets )
    line.chomp!
    # work with line
    end

    because I know it's going to be potentially invoked often - even in scripts
    that are likely to run only on small input files. But for large files where
    not every line is processed it easily divides the number of instances
    created by a factor of 2.

    Kind regards

    robert
    Robert Klemme, Feb 20, 2005
    #3
  4. Robert Klemme, 20/2/2005 12:04:
    > "Yukihiro Matsumoto" <> schrieb im Newsbeitrag
    > news:...
    >> In message "Re: destructive! operations"
    >> on Sun, 20 Feb 2005 17:22:34 +0900, Navindra Umanee
    >> <> writes:
    >>
    >> |Is it more efficient to use the destructive versions of functions in
    >> |Ruby? I know that in Lisp/Scheme destructive counterparts are usually
    >> |offered for efficiency reasons.
    >> |
    >> |Can I assume that string.gsub! is preferable to string.gsub when I
    >> |know that the side-effect won't be affecting any other code?
    >>
    >> Although most (not all) of bang methods are more efficient than their
    >> counterparts, I discourage the use of them unless the performance is
    >> really problem. "Premature optimization is the source of all evil".

    >
    >
    > Although I agree to the latter statement, I beg to differ on the general
    > remark - at least a bit. I often use this
    >
    > while ( line = gets )
    > line.chomp!
    > # work with line
    > end
    >
    > because I know it's going to be potentially invoked often - even in
    > scripts that are likely to run only on small input files. But for large
    > files where not every line is processed it easily divides the number of
    > instances created by a factor of 2.


    Bad example:

    while ( line = gets.chomp )
    # work with line
    end
    Caio Tiago Oliveira, Feb 20, 2005
    #4
  5. On Feb 20, 2005, at 5:23 PM, Caio Tiago Oliveira wrote:
    > Bad example:
    >
    > while ( line = gets.chomp )
    > # work with line
    > end


    unless ruby cow's the string and
    the copy just has a truncating length,
    then this requires copying of the line.

    Alex
    Alexander Kellett, Feb 20, 2005
    #5
  6. On Feb 20, 2005, at 10:23 AM, Caio Tiago Oliveira wrote:

    > Bad example:
    >
    > while ( line = gets.chomp )
    > # work with line
    > end


    gets() returns a String or nil. nil does not support chomp(). When
    the chomp() is inside the while loop, this isn't an issue.

    James Edward Gray II
    James Edward Gray II, Feb 20, 2005
    #6
  7. James Edward Gray II <> wrote:
    > > Bad example:
    > >
    > > while ( line = gets.chomp )
    > > # work with line
    > > end

    >
    > gets() returns a String or nil. nil does not support chomp(). When
    > the chomp() is inside the while loop, this isn't an issue.


    Often think it would be nice if "" and 0 were treated like nil. Such
    functions could then return "". Heck, NilClass.to_s and NilClass.to_i
    already return "" and 0 respectively.

    Matz talks about premature optimizations. It looks like nil was made
    this way for efficiency purposes! Can't say if it was premature
    though. :)

    Thanks for the answers!

    Cheers,
    Navin.
    Navindra Umanee, Feb 20, 2005
    #7
  8. Navindra Umanee <> wrote:
    > Often think it would be nice if "" and 0 were treated like nil. Such
    > functions could then return "". Heck, NilClass.to_s and NilClass.to_i
    > already return "" and 0 respectively.


    "false" too..

    Incidentally I tried to make "", 0 and false respond positively to
    nil?. While they did, none of the boolean tests looked at nil? to
    make their decision. I guess that's the optimized part.

    Cheers,
    Navin.
    Navindra Umanee, Feb 20, 2005
    #8
  9. Navindra Umanee wrote:
    > James Edward Gray II <> wrote:
    >
    >>>Bad example:
    >>>
    >>>while ( line = gets.chomp )
    >>> # work with line
    >>>end

    >>
    >>gets() returns a String or nil. nil does not support chomp(). When
    >>the chomp() is inside the while loop, this isn't an issue.

    >
    >
    > Often think it would be nice if "" and 0 were treated like nil. Such
    > functions could then return "".


    One problem with this suggestion that comes to mind is, what if there
    are any blank lines in the file. then gets.chomp would return "" which
    would cause the while loop to exit. Probably not what you want

    --
    Mark Sparshatt
    mark sparshatt, Feb 20, 2005
    #9
  10. mark sparshatt <> wrote:
    > One problem with this suggestion that comes to mind is, what if there
    > are any blank lines in the file. then gets.chomp would return "" which
    > would cause the while loop to exit. Probably not what you want


    Point. The chomp would make it not work here. There are many
    situations where it could be elegant though.

    Cheers,
    Navin.
    Navindra Umanee, Feb 20, 2005
    #10
  11. Navindra Umanee

    Csaba Henk Guest

    On 2005-02-20, Navindra Umanee <> wrote:
    > Often think it would be nice if "" and 0 were treated like nil. Such
    > functions could then return "". Heck, NilClass.to_s and NilClass.to_i
    > already return "" and 0 respectively.


    Now, only false and nil drop you to the "else" branch of a conditional.
    Certainly, there are cases when it' not the best behaviour, and you
    have to write extra code to get the proper control flow when you test
    against 0 and/or "".

    If it were the other way around, and "", 0 (and [], {}) would lead to
    the "else" branch as well, again, there would occur situations when it's
    not the best behaviour and you'd need to write extra code to get things
    right.

    Now the question is: which of the two behaviours is the right thing more
    often?

    My experience is that the present way is the more optimal.

    It's more cleaner as well. There is no intrinsic difference between ""
    and "a", 0 and 1, [] and [1]. It would be artificial to force an
    instance-sensitive policy when testing agains Strings, Integers and
    Arrays.

    Those guys who make a difference when using them in a conditional are
    clearly separated into their respective cages (I mean, classes). That's
    nice...

    Csaba
    Csaba Henk, Feb 20, 2005
    #11
  12. On Mon, 21 Feb 2005 06:07:58 +0900, Navindra Umanee
    <> wrote:
    > Often think it would be nice if "" and 0 were treated like nil. Such
    > functions could then return "". Heck, NilClass.to_s and NilClass.to_i
    > already return "" and 0 respectively.


    I'm far happier that they aren't.

    -austin
    --
    Austin Ziegler *
    * Alternate:
    Austin Ziegler, Feb 21, 2005
    #12
  13. Navindra Umanee

    Zach Dennis Guest

    Austin Ziegler wrote:
    > On Mon, 21 Feb 2005 06:07:58 +0900, Navindra Umanee
    > <> wrote:
    >
    >>Often think it would be nice if "" and 0 were treated like nil. Such
    >>functions could then return "". Heck, NilClass.to_s and NilClass.to_i
    >>already return "" and 0 respectively.

    >
    >
    > I'm far happier that they aren't.
    >


    +=1

    Zach
    Zach Dennis, Feb 21, 2005
    #13
  14. "Austin Ziegler" <> schrieb im Newsbeitrag
    news:...
    > On Mon, 21 Feb 2005 06:07:58 +0900, Navindra Umanee
    > <> wrote:
    > > Often think it would be nice if "" and 0 were treated like nil. Such
    > > functions could then return "". Heck, NilClass.to_s and NilClass.to_i
    > > already return "" and 0 respectively.

    >
    > I'm far happier that they aren't.


    I didn't miss this "feature" either. I suspect that an unfinished
    transition from Perl to Ruby makes people voice such whishes... :)

    Kind regards

    robert
    Robert Klemme, Feb 21, 2005
    #14
  15. On Mon, 21 Feb 2005 23:54:42 +0900, Robert Klemme <> wrote:
    > "Austin Ziegler" < > schrieb im Newsbeitrag
    > news:...
    > > On Mon, 21 Feb 2005 06:07:58 +0900, Navindra Umanee
    > > < > wrote:
    > > > Often think it would be nice if "" and 0 were treated like nil. Such
    > > > functions could then return "". Heck, NilClass.to_s and NilClass.to_i
    > > > already return "" and 0 respectively.

    > > I'm far happier that they aren't.

    > I didn't miss this "feature" either. I suspect that an unfinished
    > transition from Perl to Ruby makes people voice such whishes... :)


    Or C++/Java to Ruby (not the "", but definitely the 0). I *have* been
    bitten by 0/false problems in translations, but very few.

    -austin
    --
    Austin Ziegler *
    * Alternate:
    Austin Ziegler, Feb 21, 2005
    #15
  16. On Mon, 21 Feb 2005 23:41:13 +0900, Austin Ziegler <> wrote:
    > On Mon, 21 Feb 2005 06:07:58 +0900, Navindra Umanee
    > <> wrote:
    > > Often think it would be nice if "" and 0 were treated like nil. Such
    > > functions could then return "". Heck, NilClass.to_s and NilClass.to_i
    > > already return "" and 0 respectively.

    >
    > I'm far happier that they aren't.


    +1

    but I think the votes don't matter, as it seems matz is quite firm on this one.

    regards,

    Brian
    Brian Schröder, Feb 21, 2005
    #16
  17. On Tue, 22 Feb 2005 00:14:41 +0900, Christian Neukirchen
    <> wrote:
    > Austin Ziegler <> writes:
    >
    > > On Mon, 21 Feb 2005 06:07:58 +0900, Navindra Umanee
    > > <> wrote:
    > >> Often think it would be nice if "" and 0 were treated like nil. Such
    > >> functions could then return "". Heck, NilClass.to_s and NilClass.to_i
    > >> already return "" and 0 respectively.

    > >
    > > I'm far happier that they aren't.
    > >
    > > -austin

    >
    > Sometimes, I'd like an "eating nil" that returns itself for each
    > method call, and is false.
    >
    > Then, stuff like that would be possible
    >
    > while line = gets.ignore_if_nil.chomp
    > ...
    > end
    >
    > Maybe just a crazy idea... :)


    What would the ignore_if_nil call in your example do? Wouldn't the
    above be equivalent to

    while line = gets.chomp
    ...
    end

    Regards,

    Brian
    Brian Schröder, Feb 21, 2005
    #17
  18. Navindra Umanee

    Bill Kelly Guest

    From: "Christian Neukirchen" <>
    >
    > Sometimes, I'd like an "eating nil" that returns itself for each
    > method call, and is false.
    >
    > Then, stuff like that would be possible
    >
    > while line = gets.ignore_if_nil.chomp
    > ...
    > end
    >
    > Maybe just a crazy idea... :)


    class NilClass
    def method_missing(meth_id, *args); self; end
    end

    ?

    :)

    ObjectiveC's nil works this way.

    The downside is you don't find out as early when you
    received an unexpected nil, in situations where you
    would have preferred to be notified.


    Regards,

    Bill
    Bill Kelly, Feb 21, 2005
    #18
  19. Austin Ziegler <> wrote:
    > On Mon, 21 Feb 2005 06:07:58 +0900, Navindra Umanee
    > <> wrote:
    > > Often think it would be nice if "" and 0 were treated like nil. Such
    > > functions could then return "". Heck, NilClass.to_s and NilClass.to_i
    > > already return "" and 0 respectively.

    >
    > I'm far happier that they aren't.


    Maybe what is more annoying, is this type of inconsistency:

    irb(main):003:0> list[4..5]
    => nil
    irb(main):004:0> list[0..3]
    => []

    Ruby is riddled with these and IMHO it tends to make code that much
    more ugly.

    Cheers,
    Navin.
    Navindra Umanee, Feb 21, 2005
    #19
  20. On Tue, 22 Feb 2005 00:31:42 +0900, Navindra Umanee
    <> wrote:
    > Austin Ziegler < > wrote:
    >> On Mon, 21 Feb 2005 06:07:58 +0900, Navindra Umanee
    >> < > wrote:
    >>> Often think it would be nice if "" and 0 were treated like nil.
    >>> Such functions could then return "". Heck, NilClass.to_s and
    >>> NilClass.to_i already return "" and 0 respectively.

    >> I'm far happier that they aren't.

    > Maybe what is more annoying, is this type of inconsistency:
    >
    > irb(main):003:0> list[4..5]
    > => nil
    > irb(main):004:0> list[0..3]
    > => []
    >
    > Ruby is riddled with these and IMHO it tends to make code that much
    > more ugly.


    That's not inconsistent; you're just not understanding. Matz posted
    about this some time back and its a perfectly clear and consistent
    way of working. Let's say you have an empty Array, 'a':

    a = []
    a[0] # nil
    a[1] # nil

    That's as expected. So why does this do something that you don't
    expect?

    a[0..3] # []
    a[1..3] # nil

    Well, it's easier to look at with a non-empty array. Let's try:

    a = %w(a b c)
    a[0] # a
    a[1] # b
    a[2] # c
    a[3] # nil

    Okay, that again is as expected. But where do the indexes point?
    According to matz, the indexes are conceptually *between* elements.
    Something like:

    a b c
    0^ 1^ 2^ 3^..

    So when you start your range outside of the allowable indexes (and
    the size of the array is an allowable, but empty, index), then
    you'll get +nil+ from the #[] call. So for our above array, a[0..3]
    produces the expected result, a[3..9] produces an empty array, and
    a[4..9] produces nil.

    It's regular. It's explained. It makes sense. It just doesn't work
    like a P language. I doubt you'll find many experienced Ruby
    programmers -- or novice Ruby programmers who don't expect Ruby to
    act like a P language -- who are confused about this issue.

    -austin
    --
    Austin Ziegler *
    * Alternate:
    Austin Ziegler, Feb 21, 2005
    #20
    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. Jesus M. Salvo Jr.
    Replies:
    2
    Views:
    3,996
    robert
    Feb 11, 2006
  2. Ville Vainio
    Replies:
    11
    Views:
    467
    Ville Vainio
    Apr 6, 2005
  3. rbt

    Destructive Windows Script

    rbt, Jun 6, 2005, in forum: Python
    Replies:
    27
    Views:
    661
    John J. Lee
    Jun 10, 2005
  4. Mad Programmer
    Replies:
    18
    Views:
    794
    Jim Langston
    Sep 13, 2005
  5. Daniel Pitts

    Re: Non destructive read of socket

    Daniel Pitts, Oct 6, 2009, in forum: Java
    Replies:
    1
    Views:
    396
    Tom Anderson
    Oct 7, 2009
Loading...

Share This Page