[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

gets

jabowen

7/13/2007 3:16:00 AM

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....
16 Answers

Chris Carter

7/13/2007 3:21:00 AM

0

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

You could just do:
test1 = gets.chomp

--
Chris Carter
concentrationstudios.com
brynmawrcs.com

Robert Klemme

7/13/2007 6:25:00 AM

0

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

Cheers

robert

Chad Perrin

7/13/2007 6:50:00 AM

0

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.

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

Robert Klemme

7/13/2007 7:03:00 AM

0

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

John Joyce

7/13/2007 7:35:00 AM

0


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

Robert Dober

7/14/2007 12:17:00 PM

0

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

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

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

Chad Perrin

7/14/2007 9:55:00 PM

0

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

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

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.

--
CCD CopyWrite Chad Perrin [ http://ccd.ap... ]
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."

Robert Dober

7/14/2007 10:53:00 PM

0

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

Robert

Robert Klemme

7/14/2007 11:36:00 PM

0

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

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

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

Chad Perrin

7/15/2007 5:11:00 AM

0

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

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.

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