Is it more efficient to use the destructive versions of functions in
Ruby? I know that in Lisp/Scheme destructive counterparts are usually
offered for efficiency reasons.
Can I assume that string.gsub! is preferable to string.gsub when I
know that the side-effect won't be affecting any other code?
I find the Ruby destructive operations sometimes inconvenient to use.
For example strip! might return null where strip would return a
string. However, if it's more efficient, I'd rather use the
destructive version.
In message "Re: destructive! operations" on Sun, 20 Feb 2005 17:22:34 +0900, Navindra Umanee <navindra@cs.mcgill.ca> writes:
Is it more efficient to use the destructive versions of functions in
Ruby? I know that in Lisp/Scheme destructive counterparts are usually
offered for efficiency reasons.
Can I assume that string.gsub! is preferable to string.gsub when I
know that the side-effect won't be affecting any other code?
Although most (not all) of bang methods are more efficient than their
counterparts, I discourage the use of them unless the performance is
really problem. "Premature optimization is the source of all evil".
"Yukihiro Matsumoto" <matz@ruby-lang.org> schrieb im Newsbeitrag news:1108909479.514053.4734.nullmailer@x31.priv.netlab.jp...
Hi
>Is it more efficient to use the destructive versions of functions in
>Ruby? I know that in Lisp/Scheme destructive counterparts are usually
>offered for efficiency reasons.
>
>Can I assume that string.gsub! is preferable to string.gsub when I
>know that the side-effect won't be affecting any other code?
Although most (not all) of bang methods are more efficient than their
counterparts, I discourage the use of them unless the performance is
really problem. "Premature optimization is the source of all evil".
Although I agree to the latter statement, I beg to differ on the general remark - at least a bit. I often use this
while ( line = gets )
line.chomp!
# work with line
end
because I know it's going to be potentially invoked often - even in scripts that are likely to run only on small input files. But for large files where not every line is processed it easily divides the number of instances created by a factor of 2.
Kind regards
robert
···
In message "Re: destructive! operations" > on Sun, 20 Feb 2005 17:22:34 +0900, Navindra Umanee > <navindra@cs.mcgill.ca> writes:
"Yukihiro Matsumoto" <matz@ruby-lang.org> schrieb im Newsbeitrag news:1108909479.514053.4734.nullmailer@x31.priv.netlab.jp...
>Is it more efficient to use the destructive versions of functions in
>Ruby? I know that in Lisp/Scheme destructive counterparts are usually
>offered for efficiency reasons.
>
>Can I assume that string.gsub! is preferable to string.gsub when I
>know that the side-effect won't be affecting any other code?
Although most (not all) of bang methods are more efficient than their
counterparts, I discourage the use of them unless the performance is
really problem. "Premature optimization is the source of all evil".
Although I agree to the latter statement, I beg to differ on the general remark - at least a bit. I often use this
while ( line = gets )
line.chomp!
# work with line
end
because I know it's going to be potentially invoked often - even in scripts that are likely to run only on small input files. But for large files where not every line is processed it easily divides the number of instances created by a factor of 2.
Bad example:
while ( line = gets.chomp )
# work with line
end
···
In message "Re: destructive! operations" >> on Sun, 20 Feb 2005 17:22:34 +0900, Navindra Umanee >> <navindra@cs.mcgill.ca> writes:
Often think it would be nice if "" and 0 were treated like nil. Such
functions could then return "". Heck, NilClass.to_s and NilClass.to_i
already return "" and 0 respectively.
Matz talks about premature optimizations. It looks like nil was made
this way for efficiency purposes! Can't say if it was premature
though.
Thanks for the answers!
Cheers,
Navin.
···
James Edward Gray II <james@grayproductions.net> wrote:
> Bad example:
>
> while ( line = gets.chomp )
> # work with line
> end
gets() returns a String or nil. nil does not support chomp(). When
the chomp() is inside the while loop, this isn't an issue.
Incidentally I tried to make "", 0 and false respond positively to
nil?. While they did, none of the boolean tests looked at nil? to
make their decision. I guess that's the optimized part.
Cheers,
Navin.
···
Navindra Umanee <navindra@cs.mcgill.ca> wrote:
Often think it would be nice if "" and 0 were treated like nil. Such
functions could then return "". Heck, NilClass.to_s and NilClass.to_i
already return "" and 0 respectively.
James Edward Gray II <james@grayproductions.net> wrote:
Bad example:
while ( line = gets.chomp )
# work with line
end
gets() returns a String or nil. nil does not support chomp(). When the chomp() is inside the while loop, this isn't an issue.
Often think it would be nice if "" and 0 were treated like nil. Such
functions could then return "".
One problem with this suggestion that comes to mind is, what if there are any blank lines in the file. then gets.chomp would return "" which would cause the while loop to exit. Probably not what you want
Now, only false and nil drop you to the "else" branch of a conditional.
Certainly, there are cases when it' not the best behaviour, and you
have to write extra code to get the proper control flow when you test
against 0 and/or "".
If it were the other way around, and "", 0 (and , {}) would lead to
the "else" branch as well, again, there would occur situations when it's
not the best behaviour and you'd need to write extra code to get things
right.
Now the question is: which of the two behaviours is the right thing more
often?
My experience is that the present way is the more optimal.
It's more cleaner as well. There is no intrinsic difference between ""
and "a", 0 and 1, and [1]. It would be artificial to force an
instance-sensitive policy when testing agains Strings, Integers and
Arrays.
Those guys who make a difference when using them in a conditional are
clearly separated into their respective cages (I mean, classes). That's
nice...
Csaba
···
On 2005-02-20, Navindra Umanee <navindra@cs.mcgill.ca> wrote:
Often think it would be nice if "" and 0 were treated like nil. Such
functions could then return "". Heck, NilClass.to_s and NilClass.to_i
already return "" and 0 respectively.
On Mon, 21 Feb 2005 06:07:58 +0900, Navindra Umanee <navindra@cs.mcgill.ca> wrote:
Often think it would be nice if "" and 0 were treated like nil. Such
functions could then return "". Heck, NilClass.to_s and NilClass.to_i
already return "" and 0 respectively.
Point. The chomp would make it not work here. There are many
situations where it could be elegant though.
Cheers,
Navin.
···
mark sparshatt <msparshatt@yahoo.co.uk> wrote:
One problem with this suggestion that comes to mind is, what if there
are any blank lines in the file. then gets.chomp would return "" which
would cause the while loop to exit. Probably not what you want
On Mon, 21 Feb 2005 06:07:58 +0900, Navindra Umanee > <navindra@cs.mcgill.ca> wrote:
Often think it would be nice if "" and 0 were treated like nil. Such
functions could then return "". Heck, NilClass.to_s and NilClass.to_i
already return "" and 0 respectively.
"Austin Ziegler" <halostatue@gmail.com> schrieb im Newsbeitrag
news:9e7db91105022106401bd2e5e@mail.gmail.com...
···
On Mon, 21 Feb 2005 06:07:58 +0900, Navindra Umanee > <navindra@cs.mcgill.ca> wrote:
> Often think it would be nice if "" and 0 were treated like nil. Such
> functions could then return "". Heck, NilClass.to_s and NilClass.to_i
> already return "" and 0 respectively.
I'm far happier that they aren't.
I didn't miss this "feature" either. I suspect that an unfinished
transition from Perl to Ruby makes people voice such whishes...
but I think the votes don't matter, as it seems matz is quite firm on this one.
regards,
Brian
···
On Mon, 21 Feb 2005 23:41:13 +0900, Austin Ziegler <halostatue@gmail.com> wrote:
On Mon, 21 Feb 2005 06:07:58 +0900, Navindra Umanee > <navindra@cs.mcgill.ca> wrote:
> Often think it would be nice if "" and 0 were treated like nil. Such
> functions could then return "". Heck, NilClass.to_s and NilClass.to_i
> already return "" and 0 respectively.
Often think it would be nice if "" and 0 were treated like nil. Such
functions could then return "". Heck, NilClass.to_s and NilClass.to_i
already return "" and 0 respectively.
I'm far happier that they aren't.
-austin
Sometimes, I'd like an "eating nil" that returns itself for each
method call, and is false.
Then, stuff like that would be possible
while line = gets.ignore_if_nil.chomp
...
end
Maybe just a crazy idea...
···
On Mon, 21 Feb 2005 06:07:58 +0900, Navindra Umanee > <navindra@cs.mcgill.ca> wrote:
Ruby is riddled with these and IMHO it tends to make code that much
more ugly.
Cheers,
Navin.
···
Austin Ziegler <halostatue@gmail.com> wrote:
On Mon, 21 Feb 2005 06:07:58 +0900, Navindra Umanee > <navindra@cs.mcgill.ca> wrote:
> Often think it would be nice if "" and 0 were treated like nil. Such
> functions could then return "". Heck, NilClass.to_s and NilClass.to_i
> already return "" and 0 respectively.
Or C++/Java to Ruby (not the "", but definitely the 0). I *have* been
bitten by 0/false problems in translations, but very few.
-austin
···
On Mon, 21 Feb 2005 23:54:42 +0900, Robert Klemme <bob.news@gmx.net> wrote:
"Austin Ziegler" <halostatue@gmail.com > schrieb im Newsbeitrag
news:9e7db91105022106401bd2e5e@mail.gmail.com...
> On Mon, 21 Feb 2005 06:07:58 +0900, Navindra Umanee > > <navindra@cs.mcgill.ca > wrote:
> > Often think it would be nice if "" and 0 were treated like nil. Such
> > functions could then return "". Heck, NilClass.to_s and NilClass.to_i
> > already return "" and 0 respectively.
> I'm far happier that they aren't.
I didn't miss this "feature" either. I suspect that an unfinished
transition from Perl to Ruby makes people voice such whishes...
What would the ignore_if_nil call in your example do? Wouldn't the
above be equivalent to
while line = gets.chomp
...
end
Regards,
Brian
···
On Tue, 22 Feb 2005 00:14:41 +0900, Christian Neukirchen <chneukirchen@gmail.com> wrote:
Austin Ziegler <halostatue@gmail.com> writes:
> On Mon, 21 Feb 2005 06:07:58 +0900, Navindra Umanee > > <navindra@cs.mcgill.ca> wrote:
>> Often think it would be nice if "" and 0 were treated like nil. Such
>> functions could then return "". Heck, NilClass.to_s and NilClass.to_i
>> already return "" and 0 respectively.
>
> I'm far happier that they aren't.
>
> -austin
Sometimes, I'd like an "eating nil" that returns itself for each
method call, and is false.
