strip and its evil brother strip!

Discussion in 'Ruby' started by Aquila, Mar 19, 2005.

  1. Aquila

    Aquila Guest

    Possibly a stupid question: why does strip! of a string with a single
    character in it give nil and strip the single character?
    I don't understand the behaviour of strip!...
    --
    "May the source be with you"
    Aquila, Mar 19, 2005
    #1
    1. Advertising

  2. Aquila

    Glenn Parker Guest

    Aquila wrote:
    > Possibly a stupid question: why does strip! of a string with a single
    > character in it give nil and strip the single character?
    > I don't understand the behaviour of strip!...


    Looks like a bug to me.

    $ ruby -e 'p " x ".strip!'
    "x"

    $ ruby -e 'p "x".strip!'
    nil

    --
    Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/>
    Glenn Parker, Mar 19, 2005
    #2
    1. Advertising

  3. Glenn Parker wrote:

    > Aquila wrote:
    >
    >> Possibly a stupid question: why does strip! of a string with a single
    >> character in it give nil and strip the single character? I don't
    >> understand the behaviour of strip!...

    >
    >
    > Looks like a bug to me.
    >
    > $ ruby -e 'p " x ".strip!'
    > "x"
    >
    > $ ruby -e 'p "x".strip!'
    > nil


    This is by design. The destructive forms of built-in methods usually
    return nil when they do nothing.
    Florian Gross, Mar 19, 2005
    #3
  4. Aquila

    Jason Sweat Guest

    On Sun, 20 Mar 2005 01:07:15 +0900, Glenn Parker
    <> wrote:
    > Aquila wrote:
    > > Possibly a stupid question: why does strip! of a string with a single
    > > character in it give nil and strip the single character?
    > > I don't understand the behaviour of strip!...

    >
    > Looks like a bug to me.
    >
    > $ ruby -e 'p " x ".strip!'
    > "x"
    >
    > $ ruby -e 'p "x".strip!'
    > nil


    This came up on another thread recenly. It is a legacy behavior of the
    *! functions that they return nil if nothing changed.

    Regards,
    Jason
    http://blog.casey-sweat.us/
    Jason Sweat, Mar 19, 2005
    #4
  5. Hi --

    On Sun, 20 Mar 2005, Jason Sweat wrote:

    > On Sun, 20 Mar 2005 01:07:15 +0900, Glenn Parker
    > <> wrote:
    >> Aquila wrote:
    >>> Possibly a stupid question: why does strip! of a string with a single
    >>> character in it give nil and strip the single character?
    >>> I don't understand the behaviour of strip!...

    >>
    >> Looks like a bug to me.
    >>
    >> $ ruby -e 'p " x ".strip!'
    >> "x"
    >>
    >> $ ruby -e 'p "x".strip!'
    >> nil

    >
    > This came up on another thread recenly. It is a legacy behavior of the
    > *! functions that they return nil if nothing changed.


    I don't think it's legacy in the sense that that usually implies
    (something that's left over from an older design). That's just the
    way they behave.


    David

    --
    David A. Black
    David A. Black, Mar 19, 2005
    #5
  6. I ranted about this very behavior 2 days ago. I'm willing to do an RCR
    if anyone agrees (hint, hint).

    http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/133894


    On Sun, 20 Mar 2005 01:56:40 +0900, David A. Black <> wrote:
    > Hi --
    >
    > On Sun, 20 Mar 2005, Jason Sweat wrote:
    >
    > > On Sun, 20 Mar 2005 01:07:15 +0900, Glenn Parker
    > > <> wrote:
    > >> Aquila wrote:
    > >>> Possibly a stupid question: why does strip! of a string with a single
    > >>> character in it give nil and strip the single character?
    > >>> I don't understand the behaviour of strip!...
    > >>
    > >> Looks like a bug to me.
    > >>
    > >> $ ruby -e 'p " x ".strip!'
    > >> "x"
    > >>
    > >> $ ruby -e 'p "x".strip!'
    > >> nil

    > >
    > > This came up on another thread recenly. It is a legacy behavior of the
    > > *! functions that they return nil if nothing changed.

    >
    > I don't think it's legacy in the sense that that usually implies
    > (something that's left over from an older design). That's just the
    > way they behave.
    >
    > David
    >
    > --
    > David A. Black
    >
    >
    >
    Daniel Amelang, Mar 19, 2005
    #6
  7. Gavin Kistner, Mar 19, 2005
    #7
  8. Aquila

    Glenn Parker Guest

    Florian Gross wrote:
    >
    > This is by design. The destructive forms of built-in methods usually
    > return nil when they do nothing.


    Yup, my bad. I know (really!) that this is by design, but I got myself
    confused while writing such a simple reply.

    For me, chaining methods is part of the Ruby way. Sacrificing the
    ability to easily chain method! calls was a mistake, IMHO. I still trip
    over this anomoly, and not once have I needed the functionality that
    took its place.

    --
    Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/>
    Glenn Parker, Mar 19, 2005
    #8
  9. Glenn Parker wrote:

    >> This is by design. The destructive forms of built-in methods usually
    >> return nil when they do nothing.

    >
    > Yup, my bad. I know (really!) that this is by design, but I got myself
    > confused while writing such a simple reply.
    >
    > For me, chaining methods is part of the Ruby way. Sacrificing the
    > ability to easily chain method! calls was a mistake, IMHO. I still trip
    > over this anomoly, and not once have I needed the functionality that
    > took its place.


    I tend to disagree as destructive methods are not supposed to be
    chained. They are optimized forms when you would be doing a variable
    assignment, IMHO.

    So they are optimizations for this case:

    a = a.strip

    But not for this case:

    puts a.strip

    While you might argue that modifying a String can be faster than
    constructing a new one based on the old one, I still think that that is
    not what matz had in mind when adding them. I'm not sure if this truly
    is how this feature was meant to be used so it's probably best to take
    this with a grain of salt until matz has clarified the situation.
    Florian Gross, Mar 19, 2005
    #9
  10. Aquila

    Glenn Parker Guest

    Florian Gross wrote:
    >
    > I tend to disagree as destructive methods are not supposed to be
    > chained. They are optimized forms when you would be doing a variable
    > assignment, IMHO.
    >
    > So they are optimizations for this case:
    >
    > a = a.strip
    >
    > But not for this case:
    >
    > puts a.strip


    Who (else) ever said destructive methods are not supposed to be chained?
    I'm thinking more of this somewhat contrived, but broken, case:

    words = gets.chomp!.strip!.downcase!.gsub!(/[^a-z]/, '').split(/ /)

    Unless and until object creation overhead is greatly reduced, this is a
    worthwhile idiom.

    --
    Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/>
    Glenn Parker, Mar 19, 2005
    #10
  11. Florian Gross <> wrote:
    > So they are optimizations for this case:
    >
    > a = a.strip


    It'd be nice to similarly optimise

    a.strip!.upcase!

    without ever having to create and discard a new object.

    martin
    Martin DeMello, Mar 19, 2005
    #11
  12. Aquila

    ES Guest

    In data 3/19/2005, "Martin DeMello" <> ha
    scritto:

    >Florian Gross <> wrote:
    >> So they are optimizations for this case:
    >>
    >> a = a.strip

    >
    >It'd be nice to similarly optimise
    >
    >a.strip!.upcase!
    >
    >without ever having to create and discard a new object.


    I'd contend it's not even about optimization. Simply
    _conceptually_ it's cleaner if, when I want to change
    object x, I can actually do so rather than create a new
    object and fiddle with 'references' and 'variables'.

    >martin


    E
    ES, Mar 19, 2005
    #12
  13. Aquila

    Bill Guindon Guest

    On Sun, 20 Mar 2005 02:38:50 +0900, Glenn Parker
    <> wrote:
    > Florian Gross wrote:
    > >
    > > This is by design. The destructive forms of built-in methods usually
    > > return nil when they do nothing.

    >
    > Yup, my bad. I know (really!) that this is by design, but I got myself
    > confused while writing such a simple reply.
    >
    > For me, chaining methods is part of the Ruby way. Sacrificing the
    > ability to easily chain method! calls was a mistake, IMHO. I still trip
    > over this anomoly, and not once have I needed the functionality that
    > took its place.


    I've always wondered about the "return nil if unchanged". I don't
    believe I've ever used it, but I'm sure I've bumped into it a few
    times where I didn't want to.

    How often is this used/useful? I can see using it as part of an 'if'
    statement, just can't think of why I would.

    Anybody out there using the nil return on a regular basis? To the
    point that it's worth sacrificing chaining?

    --
    Bill Guindon (aka aGorilla)
    Bill Guindon, Mar 19, 2005
    #13
  14. On Mar 19, 2005, at 11:49 AM, Florian Gross wrote:

    > While you might argue that modifying a String can be faster than
    > constructing a new one based on the old one, I still think that that
    > is not what matz had in mind when adding them. I'm not sure if this
    > truly is how this feature was meant to be used so it's probably best
    > to take this with a grain of salt until matz has clarified the
    > situation.


    I like the current behavior and have used it in if statements more than
    once, just to throw another log on the fire...

    James Edward Gray II
    James Edward Gray II, Mar 19, 2005
    #14
  15. * Gavin Kistner (Mar 19, 2005 19:11):
    > > I ranted about this very behavior 2 days ago. I'm willing to do an
    > > RCR if anyone agrees (hint, hint).


    > > http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/133894


    > I experience the same pain, and would vote for such an RCR


    Exactly when do you experience this pain? Perhaps you need some
    aspirin?

    Seriously, if you think using bang-methods is painful, I'd suggest not
    using them at all. Use non-destructive methods instead. The
    tradeoff in speed is negligible for anyting but real large
    iteration-counts, e.g., in the area of perhaps five million and beyond.
    At that point, it'd probably be better to come up with some special
    method for doing what you're trying to do (although on my machine doing
    one million

    line.strip.downcase

    takes 1.7 seconds (the banged version takes 1.2 seconds), so I'm not
    really worried, I'd be more worried with how I'd store the result if
    that's what the task is. (Actually, I'm guessing a large portion of
    those 0.5 seconds are due to the garbage collector being invoked for the
    non-banged one, but please remember that it's only a guess.)

    I'd like to propose an RCR that would abolish the destructive versions
    of methods in String and other standard classes. They're simply too
    confusing (discussions such as these prove me right) and their uses,
    if any, are usually symptoms of code that should be written differently.

    I'm only half serious, but please realize that those methods are
    suffixed by a bang for a very good reason,
    nikolai

    P.S.
    It's strange, but the more I work with Ruby, the more I realize how
    beautiful languages like Haskell and Clean really are. There are good
    reasons for having languages free of side-effects. Still, I'd rather
    program Ruby than spend my time wrestling a type-system that makes my
    head spin.

    Remember: the great thing about dynamic languages is not that you don't
    have to write type-declarations, it's that you can write anything you
    like for all the parts of the system that never get run!
    D.S.

    --
    ::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
    ::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
    ::: page: minimalistic.org :: fun atm: gf,lps,ruby,lisp,war3 :::
    main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
    Nikolai Weibull, Mar 19, 2005
    #15
  16. Aquila

    ES Guest

    In data 3/19/2005, "James Edward Gray II" <>
    ha scritto:

    >On Mar 19, 2005, at 11:49 AM, Florian Gross wrote:
    >
    >> While you might argue that modifying a String can be faster than
    >> constructing a new one based on the old one, I still think that that
    >> is not what matz had in mind when adding them. I'm not sure if this
    >> truly is how this feature was meant to be used so it's probably best
    >> to take this with a grain of salt until matz has clarified the
    >> situation.

    >
    >I like the current behavior and have used it in if statements more than
    >once, just to throw another log on the fire...


    I can see that in some cases; on the other hand chaining
    would be enormously fun and useful.

    In the end, though, this just ties in with one of my
    firmly held beliefs: the success or failure of an
    operation should be indicated separately of its
    return value.

    >James Edward Gray II


    E
    ES, Mar 19, 2005
    #16
  17. Aquila

    Bill Kelly Guest

    From: "Bill Guindon" <>
    >
    > I've always wondered about the "return nil if unchanged". I don't
    > believe I've ever used it, but I'm sure I've bumped into it a few
    > times where I didn't want to.
    >
    > How often is this used/useful? I can see using it as part of an 'if'
    > statement, just can't think of why I would.
    >
    > Anybody out there using the nil return on a regular basis? To the
    > point that it's worth sacrificing chaining?


    I've only used it occasionally. But as Matz pointed out
    awhile back,
    http://ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/17764
    if you do need to know whether the object was modified,
    there's no other way to get that information as cheaply.


    Regards,

    Bill
    Bill Kelly, Mar 19, 2005
    #17
  18. * ES (Mar 19, 2005 22:40):
    > > > While you might argue that modifying a String can be faster than
    > > > constructing a new one based on the old one, I still think that
    > > > that is not what matz had in mind when adding them. I'm not sure
    > > > if this truly is how this feature was meant to be used so it's
    > > > probably best to take this with a grain of salt until matz has
    > > > clarified the situation.


    > > I like the current behavior and have used it in if statements more
    > > than once, just to throw another log on the fire...


    > I can see that in some cases; on the other hand chaining would be
    > enormously fun and useful.


    Fun?

    > In the end, though, this just ties in with one of my firmly held
    > beliefs: the success or failure of an operation should be indicated
    > separately of its return value.


    How would the success or failure of strip! be returned exactly?,
    nikolai

    --
    ::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
    ::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
    ::: page: minimalistic.org :: fun atm: gf,lps,ruby,lisp,war3 :::
    main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
    Nikolai Weibull, Mar 19, 2005
    #18
  19. Aquila

    ES Guest

    In data 3/19/2005, "Nikolai Weibull"
    <> ha scritto:

    >* ES (Mar 19, 2005 22:40):
    >> > > While you might argue that modifying a String can be faster than
    >> > > constructing a new one based on the old one, I still think that
    >> > > that is not what matz had in mind when adding them. I'm not sure
    >> > > if this truly is how this feature was meant to be used so it's
    >> > > probably best to take this with a grain of salt until matz has
    >> > > clarified the situation.

    >
    >> > I like the current behavior and have used it in if statements more
    >> > than once, just to throw another log on the fire...

    >
    >> I can see that in some cases; on the other hand chaining would be
    >> enormously fun and useful.

    >
    >Fun?


    'Conceptually better'.

    >> In the end, though, this just ties in with one of my firmly held
    >> beliefs: the success or failure of an operation should be indicated
    >> separately of its return value.

    >
    >How would the success or failure of strip! be returned exactly?,
    > nikolai


    Hey, I'm not a Computer Scientist :)

    It could be given via the return value wrapped inside a
    MethodCallResult [sic] structure.

    x = line.strip
    puts x if x.successful?

    It could be given as a special variable/method.

    x = line.strip
    puts x if successful?

    Or there could be an entirely new way.

    # test.rb # test_handling.rbh
    x = line.strip
    puts x pass if not strip.successful?

    E
    ES, Mar 19, 2005
    #19
  20. Nikolai Weibull <> wrote:
    > How would the success or failure of strip! be returned exactly?,


    Thread-local $variable?

    martin
    Martin DeMello, Mar 19, 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. Daniel M. Hendricks

    Regex to strip evil HTML tags

    Daniel M. Hendricks, Apr 10, 2005, in forum: ASP .Net
    Replies:
    2
    Views:
    6,022
    vMike
    Apr 11, 2005
  2. Replies:
    12
    Views:
    1,081
    Ville Vainio
    Feb 17, 2006
  3. thunk
    Replies:
    1
    Views:
    307
    thunk
    Mar 30, 2010
  4. thunk
    Replies:
    0
    Views:
    472
    thunk
    Apr 1, 2010
  5. thunk
    Replies:
    14
    Views:
    614
    thunk
    Apr 3, 2010
Loading...

Share This Page