Gets

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.

On 7/12/07, Jeffrey B. [email protected] 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

You could just do:
test1 = gets.chomp

2007/7/13, Jeffrey B. [email protected]:

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

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

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.

2007/7/13, Chad P. [email protected]:

print "test1 "
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

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

that Chris
chomp! is more efficient. If you need to make sure that an object does
Kind regards

robert

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

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 B. [email protected] wrote:

puts test1.class

____________________________________________________________________________________Ready

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

On 7/13/07, John J. [email protected] wrote:

Thanks

test1.comp
Thanks
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 Jul 13, 2007, at 8:31 AM, Jeffrey B. wrote:

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

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 5:38 PM, Logan C. wrote:

reassigning test1 to another variable IE test2 =

test.chomp will return a chomped value but doesn’t permanently chomp
Your choices are
test1.chomp!

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.

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

On 7/13/07, Robert K. [email protected] wrote:

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/14/07, Chad P. [email protected] wrote:

On Sat, Jul 14, 2007 at 09:16:35PM +0900, Robert D. 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

Robert

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

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 Sun, Jul 15, 2007 at 08:40:10AM +0900, Robert K. wrote:

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.

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 15.07.2007 00:52, Robert D. wrote:

On 7/14/07, Chad P. [email protected] wrote:

On Sat, Jul 14, 2007 at 09:16:35PM +0900, Robert D. 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

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

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

On 7/15/07, SonOfLilit [email protected] 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.
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, Chad P. [email protected] wrote:

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 P. [ 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

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

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