Strip and its evil brother strip!

ruby-talk
1

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"

2

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/&gt;

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.

4

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/

···

On Sun, 20 Mar 2005 01:07:15 +0900, Glenn Parker <glenn.parker@comcast.net> 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

5

Hi --

···

On Sun, 20 Mar 2005, Jason Sweat wrote:

On Sun, 20 Mar 2005 01:07:15 +0900, Glenn Parker > <glenn.parker@comcast.net> 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
dblack@wobblini.net

6

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/&gt;

7

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 <dblack@wobblini.net> wrote:

Hi --

On Sun, 20 Mar 2005, Jason Sweat wrote:

> On Sun, 20 Mar 2005 01:07:15 +0900, Glenn Parker > > <glenn.parker@comcast.net> 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
dblack@wobblini.net

8

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.

9

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?

···

On Sun, 20 Mar 2005 02:38:50 +0900, Glenn Parker <glenn.parker@comcast.net> 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.

--
Bill Guindon (aka aGorilla)

10

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

···

On Mar 19, 2005, at 10:04 AM, Daniel Amelang wrote:

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

11

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/&gt;

12

It'd be nice to similarly optimise

a.strip!.upcase!

without ever having to create and discard a new object.

martin

···

Florian Gross <flgr@ccan.de> wrote:

So they are optimizations for this case:

a = a.strip

13

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

···

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.

14

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

···

From: "Bill Guindon" <agorilla@gmail.com>

15

One thing I dislike about the Smalltalk-style habit of returning self when
there is otherwise no return value, is that this return value is something
you already have, and it gets in the way of ex-post-facto extending your
interface by making the method return a meaningful value.

In the case of Ruby, the return value is essentially a boolean telling you
whether any modifications had to be done, but somehow, instead of using
true vs false, it's self vs nil. I don't know why.

Smalltalk also has an alternate mechanism at the syntax level, for making
several methodcalls to a receiver written only once. This makes returning
self sound even stupider to me in that context. I wish Ruby had a similar
feature so that methods never have to return systematically self and so
whenever such a thread appears we could point people to that feature.

Example (with some extra spaces inserted, and supposing there are methods
named like that in Smalltalk)

  Smalltalk: x chop strip.
  Ruby: x.chop! .strip!

  Smalltalk: x chop. x strip.
  Ruby: x.chop!; x.strip!

  Smalltalk: x chop; strip.
  Ruby (no equivalent)

In the last version, x is only mentioned once, and the return value of
chop is discarded. I think it could be nice to have something like that in
Ruby.

···

On Sun, 20 Mar 2005, Daniel Amelang wrote:

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

_____________________________________________________________________
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju

16

In data 3/19/2005, "Martin DeMello" <martindemello@yahoo.com> ha
scritto:

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

···

Florian Gross <flgr@ccan.de> wrote:

17

* 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);}

18

ha scritto:

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

···

In data 3/19/2005, "James Edward Gray II" <james@grayproductions.net>

On Mar 19, 2005, at 11:49 AM, Florian Gross wrote:

19

Mathieu Bouchard <matju@sympatico.ca> writes:

  Smalltalk: x chop; strip.
  Ruby (no equivalent)

In the last version, x is only mentioned once, and the return value of
chop is discarded. I think it could be nice to have something like that in
Ruby.

Perhaps:

  x.instance_eval{chop!; strip!}

Alias to taste. Locals can get in the way for most method names,
though.

20

Mathieu Bouchard <matju@sympatico.ca> writes:

Smalltalk also has an alternate mechanism at the syntax level, for making
several methodcalls to a receiver written only once. This makes returning
self sound even stupider to me in that context. I wish Ruby had a similar
feature so that methods never have to return systematically self and so
whenever such a thread appears we could point people to that feature.

+1

Example (with some extra spaces inserted, and supposing there are methods
named like that in Smalltalk)

  Smalltalk: x chop strip.
  Ruby: x.chop! .strip!

  Smalltalk: x chop. x strip.
  Ruby: x.chop!; x.strip!

  Smalltalk: x chop; strip.
  Ruby (no equivalent)

In the last version, x is only mentioned once, and the return value of
chop is discarded. I think it could be nice to have something like that in
Ruby.

For Ruby2, I'd love to have this too.

···

On Sun, 20 Mar 2005, Daniel Amelang wrote:

Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org