YANAGAWA Kazuhisa proposed a method String#clear. The
method set the string empty, like Array#clear for Array.
It can be defined in Ruby as follows:
class String
def clear
replace ""
end
end
[ruby-dev:18465] warning for outer local variable assignment by block parameter
Tanaka Akira proposed warning for outer local variable assignment
by block parameter.
(ex.)
i = 0
foo.each{|i| ## <= warning
…
GOTO Kentaro doubted if it is not the rare conditions, but Matz
thinks that the frequency is not much for the risk, so it will
be implemented.
[ruby-dev:18482] mem leak?
WATANABE Tetsuya pointed out that in 1.7.3(at 10/10 morning)
a script which uses large objects consumes huge memory and it
leads pageout.
Akira Tanaka suggested that GC should be triggered when
the amount of the allocated memory is more than two times
of the memory which used by live objects.
Nobuyoshi Nakada made a patch ([ruby-dev:18487]) and commited
it.
Akira Tanaka suggested that GC should be triggered when
the amount of the allocated memory is more than two times
of the memory which used by live objects.
Nobuyoshi Nakada made a patch ([ruby-dev:18487]) and commited
it.
If this is now considered “bad style”, why was it allowed at
the beginning? I thought that the current semantics were the
result of a trade-off between expressive power/performance and
inability-to-shoot-yourself-in-the-foot.
matz’s latest proposal clearly showed that he thought that assigning
to an external variable was justified in some occasions, and now he’s
kinda saying that it should be avoided???
···
On Wed, Oct 16, 2002 at 06:48:45AM +0900, TAKAHASHI Masayoshi wrote:
Hi all,
Sorry to post so late. This is a summary of ruby-dev ML
in these days.
[ruby-dev:18465] warning for outer local variable assignment by block parameter
Tanaka Akira proposed warning for outer local variable assignment
by block parameter.
(ex.)
i = 0
foo.each{|i| ## <= warning
…
GOTO Kentaro doubted if it is not the rare conditions, but Matz
thinks that the frequency is not much for the risk, so it will
be implemented.
matz's latest proposal clearly showed that he thought that assigning
to an external variable was justified in some occasions, and now he's
kinda saying that it should be avoided???
Well, the latest that I know is [ruby-talk:52440] where there is
[...]
* variables assigned by ":=" should be local to the block (or
possibly local to the nearest compound statements).
* if ":=" assignee is already defined in outer scope, it should be
warned (no -w needed, probably), and outer variable is shadowed
hereafter.
* all local variables in block parameters (e.g. var in |var|) should
be treated as if they are assigned by ":=". other types of
variables in block parameter should be warned.
[...]
If this is now considered “bad style”, why was it allowed at
the beginning? I thought that the current semantics were the
result of a trade-off between expressive power/performance and
inability-to-shoot-yourself-in-the-foot.
Because I was stupid. This is bad manner.
matz’s latest proposal clearly showed that he thought that assigning
to an external variable was justified in some occasions, and now he’s
kinda saying that it should be avoided???
I think I just said “it’s possible”. But it doesn’t mean it is
encouraged. And I’m saying it should be avoided.
matz.
···
In message “Re: ruby-dev summary 18458-18504” on 02/10/16, Mauricio Fernández batsman.geo@yahoo.com writes:
Read [ruby-talk:53308] you don’t find something strange ?
Yes, it does look strange. Why bother assigning nil to r and w if the
value is just going to be thrown away?
Paul
I believe that if the people who originally wrote the library code did it
again, their collected experience in Ruby would cause them to write them in a
better style.
These and the sample code deserve to be revisited, but it’s hardly as high
priority.
This looks to me like some performance fine tuning which is achieved
through some non-explicit language facility. Probably it is time to
consider something like what Pyrex has done for Python? (I.e., if we want
to increase performance, in my opinion, it is better to do it using some
explicit facility instead of creating some “rather confusing” code).
Also, the technique “pure local variables are faster than block local
variables” will seem inconsistent when (and if) we have explicit block
local variables in the future (such as using “:=”, “_var”, “local”, “;”,
etc.).
