From: Robert Klemme Date: 2003-01-31T23:25:30+09:00 Subject: Re: Local variables & blocks "Yukihiro Matsumoto" schrieb im Newsbeitrag news:1043933439.835669.17626.nullmailer@picachu.netlab.jp... > Hi, > > In message "Re: Local variables & blocks" > on 03/01/30, "Robert Klemme" writes: > > |Just to make sure: From what I read in this thread there are quite some > |situations which could be problematic with exporting a variable from a > |block to its enclosing scope. Are all these situations properly regarded? > | > |I still feel a unwary about this change... > > Describe your feeling and ideas. This is why I post. What kind of > situations do you think this change does not cover properly? (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. (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. (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. 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? Regards robert