From: matz@... (Yukihiro Matsumoto) Date: 2003-02-01T00:20:30+09:00 Subject: Re: Local variables & blocks Hi, In message "Re: Local variables & blocks" on 03/01/31, "Robert Klemme" writes: |(i) It's that the control is reversed. Currently the enclosing scope |defines variables that are visible in the block. This is common behavior |for most languages and people are used to it. But these "most languages" have declaration. So Ruby can (and does) act differently. |(ii) I don't find it too hard to declare a variable outside the block in |order to be able to use it inside and after the block. So I personally |would not gain much. I gain much, so it's OK for me. Am I too selfish? ;-) Since Ruby has no explicit declaration, it is sometimes very hard to tell whether an identifier is already used as an local variable or not. This makes code difficult to read. |(iii) Binding is deferred to execution time. Currently I don't fully |oversee all implications of this. Here are some thoughts: It could const |performance. Runtime errors vs. compile time erros. Errors might be hard to |track down: think of someone creating a Proc instance, handing that to a |method that invokes another method etc. until it arrives in the method that |finally uses it. Maybe the block comes from a different module. Now I |suddenly get errors because the block creates variables in my method's |scope, instead of beeing restricted to the creator's scope. I'm not sure what you mean. Maybe you're worrying about something I don't intend. Sorry if I was too terse. |With the change, will it be possible to do something like this a bit |artifical example? | |class C | def initialize | @has_run = false | end | | def createProc | Proc.new { @has_run = true } | end | | def has_run? | has_run | end |end | |c = C.new |p = c.createProc | |c.has_run? | |a = [] |a.each { p.call } |c.has_run? | |a << 1 << 2 |a.each { p.call } |c.has_run? Nothing will change regarding this script behavior (suppose "has_run" in "has_run?" method is "@has_run"). matz.