Gets

ruby-talk
1

Of course the code below will not work because gets is
adding /n to the entry. I know that chomp will remove
the /n but is there away to cut the /n without
reassigning test1 to another variable IE test2 =
test1.comp

print "test1 "
test1 = gets
puts test1.class
if test1 == "1"
        puts "step 1"
else
        puts "step 2"
end

Thanks
Jeff

____________________________________________________________________________________Ready for the edge of your seat?
Check out tonight's top picks on Yahoo! TV.
http://tv.yahoo.com/

2

You could just do:
test1 = gets.chomp

···

On 7/12/07, Jeffrey Bowen <ja_bowen@yahoo.com> wrote:

Of course the code below will not work because gets is
adding /n to the entry. I know that chomp will remove
the /n but is there away to cut the /n without
reassigning test1 to another variable IE test2 =
test1.comp

--
Chris Carter
concentrationstudios.com
brynmawrcs.com

3

Of course the code below will not work because gets is
adding /n to the entry. I know that chomp will remove
the /n but is there away to cut the /n without
reassigning test1 to another variable IE test2 =
test1.comp

Use chomp!

print "test1 "
test1 = gets
puts test1.class
if test1 == "1"
        puts "step 1"
else
        puts "step 2"
end

Cheers

robert

···

2007/7/13, Jeffrey Bowen <ja_bowen@yahoo.com>:

4

Thanks
Sometime I'm just slow. I tried
"test.chomp = gets" but I didn't try "test =
gets.chomp". The error message most likely told me
what was wrong.

Thanks
Jeff

Of course the code below will not work because gets
is
adding /n to the entry. I know that chomp will
remove
the /n but is there away to cut the /n without
reassigning test1 to another variable IE test2 =
test1.comp

print "test1 "
test1 = gets
puts test1.class
if test1 == "1"
        puts "step 1"
else
        puts "step 2"
end

Thanks
Jeff

____________________________________________________________________________________Ready

···

--- Jeffrey Bowen <ja_bowen@yahoo.com> wrote:

for the edge of your seat?
Check out tonight's top picks on Yahoo! TV.
http://tv.yahoo.com/

      ____________________________________________________________________________________
Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7

5

That was the first thing that occurred to me, too, but I think that Chris
Carter's solution is (usually) the better option. In-place modification
can lead to some difficult-to-track bugs when working with complex code,
and can also be problematic for concurrency -- so I try to stay in the
habit of avoiding in-place modifications.

···

On Fri, Jul 13, 2007 at 03:24:30PM +0900, Robert Klemme wrote:

2007/7/13, Jeffrey Bowen <ja_bowen@yahoo.com>:
>Of course the code below will not work because gets is
>adding /n to the entry. I know that chomp will remove
>the /n but is there away to cut the /n without
>reassigning test1 to another variable IE test2 =
>test1.comp

Use chomp!

>print "test1 "
>test1 = gets
>puts test1.class
>if test1 == "1"
> puts "step 1"
>else
> puts "step 2"
>end

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Kent Beck: "I always knew that one day Smalltalk would replace Java. I
just didn't know it would be called Ruby."

6

test.chomp = gets

and

test = gets.chomp

Will give you different results.
test.chomp will return a chomped value but doesn't permanently chomp the value in test
you would need to do

test.chomp! = gets

This is the destructive version of chomp, methods ending with ! usually modify the receiver in place, others usually don't.
The reason my version doesn't need chomp! is because it takes the chomped value of gets and assigns that to test.

···

On Jul 13, 2007, at 8:31 AM, Jeffrey Bowen wrote:

Thanks
Sometime I'm just slow. I tried
"test.chomp = gets" but I didn't try "test =
gets.chomp". The error message most likely told me
what was wrong.

Thanks
Jeff

--- Jeffrey Bowen <ja_bowen@yahoo.com> wrote:

Of course the code below will not work because gets
is
adding /n to the entry. I know that chomp will
remove
the /n but is there away to cut the /n without
reassigning test1 to another variable IE test2 =
test1.comp

print "test1 "
test1 = gets
puts test1.class
if test1 == "1"
        puts "step 1"
else
        puts "step 2"
end

Thanks
Jeff

7

You're over cautious here. Your concerns do not apply because test1 is
a local variable and this bit of code is far from complex. Also,
chomp! is more efficient. If you need to make sure that an object does
not change you can use #freeze and be sure to immediately detect bugs
(i.e. unwanted modifications).

Apart from that, every Array append operation is an inplace
modification. Changing an object's state is at the core of OO
programming - so avoiding it is not realistic.

If you follow your thought consequently to the end you should switch
to a pure functional language because that is free of side effects.

Kind regards

robert

···

2007/7/13, Chad Perrin <perrin@apotheon.com>:

On Fri, Jul 13, 2007 at 03:24:30PM +0900, Robert Klemme wrote:
> 2007/7/13, Jeffrey Bowen <ja_bowen@yahoo.com>:
> >Of course the code below will not work because gets is
> >adding /n to the entry. I know that chomp will remove
> >the /n but is there away to cut the /n without
> >reassigning test1 to another variable IE test2 =
> >test1.comp
>
> Use chomp!
>
> >print "test1 "
> >test1 = gets
> >puts test1.class
> >if test1 == "1"
> > puts "step 1"
> >else
> > puts "step 2"
> >end

That was the first thing that occurred to me, too, but I think that Chris
Carter's solution is (usually) the better option. In-place modification
can lead to some difficult-to-track bugs when working with complex code,
and can also be problematic for concurrency -- so I try to stay in the
habit of avoiding in-place modifications.

8

> Thanks
> Sometime I'm just slow. I tried
> "test.chomp = gets" but I didn't try "test =
> gets.chomp". The error message most likely told me
> what was wrong.
>
> Thanks
> Jeff
>
>> Of course the code below will not work because gets
>> is
>> adding /n to the entry. I know that chomp will
>> remove
>> the /n but is there away to cut the /n without
>> reassigning test1 to another variable IE test2 =
>> test1.comp
>>
>> print "test1 "
>> test1 = gets
>> puts test1.class
>> if test1 == "1"
>> puts "step 1"
>> else
>> puts "step 2"
>> end
>>
>> Thanks
>> Jeff
>>
test.chomp = gets

and

test = gets.chomp

Will give you different results.
test.chomp will return a chomped value but doesn't permanently chomp
the value in test
you would need to do

test.chomp! = gets

You can't do this. (At least not using that syntax). Furthermore it would
not be able to have the desired semantics anyway.

Your choices are
test1 = gets.chomp

OR

test1 = gets
test1 = test1.chomp

OR

test1 = gets
test1.chomp!

OR

test1 = gets.chomp! # will work in this case, not a good idea from a best
practices POV

I mighta missed a variation, but you definitely can't do test1.chomp! =
gets. That's nonsense.

This is the destructive version of chomp, methods ending with !

···

On 7/13/07, John Joyce <dangerwillrobinsondanger@gmail.com> wrote:

On Jul 13, 2007, at 8:31 AM, Jeffrey Bowen wrote:
> --- Jeffrey Bowen <ja_bowen@yahoo.com> wrote:
usually modify the receiver in place, others usually don't.
The reason my version doesn't need chomp! is because it takes the
chomped value of gets and assigns that to test.

9

this is definitely a case where the usual action people take is
variable_name = gets.chomp
The only time you would not do that, is if you actually want/need the \n character for something.
You can always add it back later very easily if you need it.
variable_name += '\n'
This concatenates it to the stored string.
(technically it takes the result of concatenating the string in variable_name with the immediate string value of the newline character and then assigns the result to the original variable.
chomp is one of those good ideas that came from perl because it's so often needed.

John Joyce

···

On Jul 13, 2007, at 2:03 AM, Robert Klemme wrote:

2007/7/13, Chad Perrin <perrin@apotheon.com>:

On Fri, Jul 13, 2007 at 03:24:30PM +0900, Robert Klemme wrote:
> 2007/7/13, Jeffrey Bowen <ja_bowen@yahoo.com>:
> >Of course the code below will not work because gets is
> >adding /n to the entry. I know that chomp will remove
> >the /n but is there away to cut the /n without
> >reassigning test1 to another variable IE test2 =
> >test1.comp
>
> Use chomp!
>
> >print "test1 "
> >test1 = gets
> >puts test1.class
> >if test1 == "1"
> > puts "step 1"
> >else
> > puts "step 2"
> >end

That was the first thing that occurred to me, too, but I think that Chris
Carter's solution is (usually) the better option. In-place modification
can lead to some difficult-to-track bugs when working with complex code,
and can also be problematic for concurrency -- so I try to stay in the
habit of avoiding in-place modifications.

You're over cautious here. Your concerns do not apply because test1 is
a local variable and this bit of code is far from complex. Also,
chomp! is more efficient. If you need to make sure that an object does
not change you can use #freeze and be sure to immediately detect bugs
(i.e. unwanted modifications).

Apart from that, every Array append operation is an inplace
modification. Changing an object's state is at the core of OO
programming - so avoiding it is not realistic.

If you follow your thought consequently to the end you should switch
to a pure functional language because that is free of side effects.

Kind regards

robert

10

You're right I got ahead of myself while typing!
JJ

···

On Jul 13, 2007, at 5:38 PM, Logan Capaldo wrote:

On 7/13/07, John Joyce <dangerwillrobinsondanger@gmail.com> wrote:

On Jul 13, 2007, at 8:31 AM, Jeffrey Bowen wrote:

> Thanks
> Sometime I'm just slow. I tried
> "test.chomp = gets" but I didn't try "test =
> gets.chomp". The error message most likely told me
> what was wrong.
>
> Thanks
> Jeff
>
> --- Jeffrey Bowen <ja_bowen@yahoo.com> wrote:
>
>> Of course the code below will not work because gets
>> is
>> adding /n to the entry. I know that chomp will
>> remove
>> the /n but is there away to cut the /n without
>> reassigning test1 to another variable IE test2 =
>> test1.comp
>>
>> print "test1 "
>> test1 = gets
>> puts test1.class
>> if test1 == "1"
>> puts "step 1"
>> else
>> puts "step 2"
>> end
>>
>> Thanks
>> Jeff
>>
test.chomp = gets

and

test = gets.chomp

Will give you different results.
test.chomp will return a chomped value but doesn't permanently chomp
the value in test
you would need to do

test.chomp! = gets

You can't do this. (At least not using that syntax). Furthermore it would
not be able to have the desired semantics anyway.

Your choices are
test1 = gets.chomp

OR

test1 = gets
test1 = test1.chomp

OR

test1 = gets
test1.chomp!

OR

test1 = gets.chomp! # will work in this case, not a good idea from a best
practices POV

I mighta missed a variation, but you definitely can't do test1.chomp! =
gets. That's nonsense.

This is the destructive version of chomp, methods ending with !

usually modify the receiver in place, others usually don't.
The reason my version doesn't need chomp! is because it takes the
chomped value of gets and assigns that to test.

11

> > >Of course the code below will not work because gets is
> > >adding /n to the entry. I know that chomp will remove
> > >the /n but is there away to cut the /n without
> > >reassigning test1 to another variable IE test2 =
> > >test1.comp
> >
> > Use chomp!
> >
> > >print "test1 "
> > >test1 = gets
> > >puts test1.class
> > >if test1 == "1"
> > > puts "step 1"
> > >else
> > > puts "step 2"
> > >end
>
> That was the first thing that occurred to me, too, but I think that Chris
> Carter's solution is (usually) the better option. In-place modification
> can lead to some difficult-to-track bugs when working with complex code,
> and can also be problematic for concurrency -- so I try to stay in the
> habit of avoiding in-place modifications.

You're over cautious here. Your concerns do not apply because test1 is
a local variable and this bit of code is far from complex. Also,
chomp! is more efficient. If you need to make sure that an object does
not change you can use #freeze and be sure to immediately detect bugs
(i.e. unwanted modifications).

Robert I am a big fan of in place modification and you have already
explained the thread safety of local variables very well to me on this
list.
Furthermore all you say here is technically very sound...
... am I about to back you up on this?
Actually no, well your post is relevant and technical interesting but
I feel that Chad's approach is quite elegant.
Maybe his motivation is wrong, I do not want to make a statement about
it, but I feel that his code is cleaner, more functional oriented,
more modern in some way...

What you have said will be worth gold when we have to optimize the
code but maybe it is premature optimization right now.

Just some thoughts, after all both solution seem very reasonable to me :slight_smile:

Apart from that, every Array append operation is an inplace
modification. Changing an object's state is at the core of OO
programming - so avoiding it is not realistic.

Hmm not sure it might not be possible to strive for some common goals
of pure functional and OO, but not an expert at all, just a thinker :wink:

If you follow your thought consequently to the end you should switch
to a pure functional language because that is free of side effects.

Voilà, but I do not like too strict categorization.

Kind regards

robert

Robert

···

On 7/13/07, Robert Klemme <shortcutter@googlemail.com> wrote:

2007/7/13, Chad Perrin <perrin@apotheon.com>:
> On Fri, Jul 13, 2007 at 03:24:30PM +0900, Robert Klemme wrote:
> > 2007/7/13, Jeffrey Bowen <ja_bowen@yahoo.com>:

--
I always knew that one day Smalltalk would replace Java.
I just didn't know it would be called Ruby
-- Kent Beck

12

Actually no, well your post is relevant and technical interesting but
I feel that Chad's approach is quite elegant.
Maybe his motivation is wrong, I do not want to make a statement about
it, but I feel that his code is cleaner, more functional oriented,
more modern in some way...

Thanks.

What you have said will be worth gold when we have to optimize the
code but maybe it is premature optimization right now.

I wasn't even aware that "foo = gets; foo.chomp!" would be more efficient
than "foo = gets.chomp" -- that's news to me, and I'm not sure I get why
that should be the case at the moment. Even so, I tend to agree --
except in very limited circumstances, I think choosing the former over
the latter because of efficiency is a case of premature optimization.

Just some thoughts, after all both solution seem very reasonable to me :slight_smile:

True. In the very limited case of these examples, we're kinda making a
mountain out of a molehill.

>
>Apart from that, every Array append operation is an inplace
>modification. Changing an object's state is at the core of OO
>programming - so avoiding it is not realistic.
Hmm not sure it might not be possible to strive for some common goals
of pure functional and OO, but not an expert at all, just a thinker :wink:

It's also worth noting that I never said we should never under any
circumstances do in-place modifications.

>
>If you follow your thought consequently to the end you should switch
>to a pure functional language because that is free of side effects.
Voil?, but I do not like too strict categorization.

I wasn't aiming in that direction, anyway. Somehow, I don't think
preferring "foo = gets.chomp" over "foo = gets; foo.chomp!" makes me a
candidate for never ever using Ruby again because "everything must be
functional". I'm not sure why such a "love it or leave it" approach to
equating OOP with in-place modification whenever possible was brought up
in the first place.

···

On Sat, Jul 14, 2007 at 09:16:35PM +0900, Robert Dober wrote:

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Leon Festinger: "A man with a conviction is a hard man to change. Tell him
you disagree and he turns away. Show him facts and figures and he questions
your sources. Appeal to logic and he fails to see your point."

13

My bad, I thought it was
foo = foo.chomp vs. foo.chomp!
sorry

Robert

···

On 7/14/07, Chad Perrin <perrin@apotheon.com> wrote:

On Sat, Jul 14, 2007 at 09:16:35PM +0900, Robert Dober wrote:

I wasn't even aware that "foo = gets; foo.chomp!" would be more efficient
than "foo = gets.chomp" -- that's news to me, and I'm not sure I get why
that should be the case at the moment.

14

I wasn't even aware that "foo = gets; foo.chomp!" would be more efficient
than "foo = gets.chomp" -- that's news to me, and I'm not sure I get why
that should be the case at the moment. Even so, I tend to agree --
except in very limited circumstances, I think choosing the former over
the latter because of efficiency is a case of premature optimization.

foo = gets.chomp! # eat the cake and leave it whole

15

Actually you can have

foo = gets.chomp

as well as

foo = gets
foo.chomp!

as well as

foo = gets.chomp!

I usually do

ARGF.each do |line|
   line.chomp!
   ...
end

Which probably also explains why I use chomp!. :slight_smile:

With regard to premature optimization: I just made it a habit to use chomp! in this case because I dislike creating an object that is immediately thrown away when I can avoid it easily. I'm not religious here - it's just my personal rule of thumb. As I said "inplace modification" is nothing special, it's just the normal OO way of doing things: object state changes. Maybe people tend to forget that String and Fixnum are objects just like any other object (ok Fixnum is immutable and immediate but that's about it) and maybe that's the reason why they feel that inplace modification is special or bad. Dunno. Chad mentioned issues that can arise in complex code from inplace modification and took that as his personal guideline to avoid it. I have a different personal guideline...

Kind regards

  robert

···

On 15.07.2007 00:52, Robert Dober wrote:

On 7/14/07, Chad Perrin <perrin@apotheon.com> wrote:

On Sat, Jul 14, 2007 at 09:16:35PM +0900, Robert Dober wrote:

I wasn't even aware that "foo = gets; foo.chomp!" would be more efficient
than "foo = gets.chomp" -- that's news to me, and I'm not sure I get why
that should be the case at the moment.

My bad, I thought it was
foo = foo.chomp vs. foo.chomp!
sorry

16

> I wasn't even aware that "foo = gets; foo.chomp!" would be more efficient
> than "foo = gets.chomp" -- that's news to me, and I'm not sure I get why
> that should be the case at the moment.

Hmm it should not, but I am quite sure it is right now, maybe a
language guru can tell me better, but I am afraid that the allocation
of memory for a temporary copy of the string returned by gets is not
optimized away.
Naively I think this will happen
tmp1 = gets
tmp2 = tmp1.dup
tmp2.chomp!
foo = tmp2

and not
foo = gets
foo.chomp!

Anybody know how this is compiled by YARV?

> Even so, I tend to agree --
> except in very limited circumstances, I think choosing the former over
> the latter because of efficiency is a case of premature optimization.

I do not agree precisely, efficiency is a case of premature
optimization iff there is a price to pay for it, and I think there is
in our case...
When all things are equal I prefer the efficent code e.g.
s << "a"
instead of
s += "a"

Robert

···

On 7/15/07, SonOfLilit <sonoflilit@gmail.com> wrote:

--
I always knew that one day Smalltalk would replace Java.
I just didn't know it would be called Ruby
-- Kent Beck

17

Hi --

···

On Sun, 15 Jul 2007, SonOfLilit wrote:

I wasn't even aware that "foo = gets; foo.chomp!" would be more efficient
than "foo = gets.chomp" -- that's news to me, and I'm not sure I get why
that should be the case at the moment. Even so, I tend to agree --
except in very limited circumstances, I think choosing the former over
the latter because of efficiency is a case of premature optimization.

foo = gets.chomp! # eat the cake and leave it whole

That could get you into trouble:

   $ echo -n "abc" | ruby -e 'puts gets.chomp!'
   nil

David

--
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242\)
   RUBY FOR RAILS (http://www.manning.com/black\)
* Ruby/Rails training
     & consulting: Ruby Power and Light, LLC (http://www.rubypal.com)

18

My personal guideline is basically to avoid in-place modification unless
I have specific reason to use it. I find that an approach more
reminiscent of functional style lends itself to readability as well as
technical benefits for complex code, generally -- and when it doesn't,
that qualifies as "specific reason to use" in-place modification.

I guess there's a sort of fuzzy area in the middle where one tends to
lean one way or the other, based on personal preferences.

···

On Sun, Jul 15, 2007 at 08:40:10AM +0900, Robert Klemme wrote:

With regard to premature optimization: I just made it a habit to use
chomp! in this case because I dislike creating an object that is
immediately thrown away when I can avoid it easily. I'm not religious
here - it's just my personal rule of thumb. As I said "inplace
modification" is nothing special, it's just the normal OO way of doing
things: object state changes. Maybe people tend to forget that String
and Fixnum are objects just like any other object (ok Fixnum is
immutable and immediate but that's about it) and maybe that's the reason
why they feel that inplace modification is special or bad. Dunno. Chad
mentioned issues that can arise in complex code from inplace
modification and took that as his personal guideline to avoid it. I
have a different personal guideline...

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Amazon.com interview candidate: "When C++ is your hammer, everything starts
to look like your thumb."

19

<snip>

That could get you into trouble:

   $ echo -n "abc" | ruby -e 'puts gets.chomp!'
   nil

David

Oh noooo
of course David is right, let me be just a little be more explicit
507/7 > irb
irb(main):001:0> 'ab'.chomp!
=> nil
that really hurts

Robert

···

--
I always knew that one day Smalltalk would replace Java.
I just didn't know it would be called Ruby
-- Kent Beck

20

>
> With regard to premature optimization: I just made it a habit to use
> chomp! in this case because I dislike creating an object that is
> immediately thrown away when I can avoid it easily. I'm not religious
> here - it's just my personal rule of thumb. As I said "inplace
> modification" is nothing special, it's just the normal OO way of doing
> things: object state changes. Maybe people tend to forget that String
> and Fixnum are objects just like any other object (ok Fixnum is
> immutable and immediate but that's about it) and maybe that's the reason
> why they feel that inplace modification is special or bad. Dunno. Chad
> mentioned issues that can arise in complex code from inplace
> modification and took that as his personal guideline to avoid it. I
> have a different personal guideline...

My personal guideline is basically to avoid in-place modification unless
I have specific reason to use it. I find that an approach more
reminiscent of functional style lends itself to readability as well as
technical benefits for complex code, generally -- and when it doesn't,
that qualifies as "specific reason to use" in-place modification.

Yeah Robert, that was my feeling and that's what I really wanted to
discuss, sorry if I got too offensive. I know I often forget the "?"
when asking questions. :frowning:

After some thoughts I just have to say that Chad seems to make his
life easier than I make mine and I will consider his style in the
future too.

Conclusion, as this seemed to be quite a simple question, there are no
simple questions :wink:

I guess there's a sort of fuzzy area in the middle where one tends to
lean one way or the other, based on personal preferences.

Yup and that's the interesting stuff

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Amazon.com interview candidate: "When C++ is your hammer, everything starts
to look like your thumb."

Hey I never read this one, GREAT!!!

Robert

···

On 7/15/07, Chad Perrin <perrin@apotheon.com> wrote:

On Sun, Jul 15, 2007 at 08:40:10AM +0900, Robert Klemme wrote:

--
I always knew that one day Smalltalk would replace Java.
I just didn't know it would be called Ruby
-- Kent Beck