strip and its evil brother strip!

[Aquila]

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!...

 

[Glenn Parker]

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

 

[Florian Gross]

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.

 

[Jason Sweat]

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/

 

[David A. Black]

Hi --

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

 

[Daniel Amelang]

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

 

[Gavin Kistner]

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

 

[Glenn Parker]

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.

 

[Florian Gross]

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.

 

[Glenn Parker]

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.

 

[Martin DeMello]

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

 

[ES]

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

 

[Bill Guindon]

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?

 

[James Edward Gray II]

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

 

[Nikolai Weibull]

* Gavin Kistner (Mar 19, 2005 19:11):

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.

 

[ES]

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

 

[Bill Kelly]

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

 

[Nikolai Weibull]

* ES (Mar 19, 2005 22:40):

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

 

[ES]

In data 3/19/2005, "Nikolai Weibull"

* ES (Mar 19, 2005 22:40):


Fun?

'Conceptually better'.

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

 

[Martin DeMello]

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

Thread-local $variable?

martin