From: Yukihiro Matsumoto Date: 2009-07-19T02:06:03+09:00 Subject: [ruby-core:24431] Re: lvar_propagate Hi, In message "Re: [ruby-core:24421] lvar_propagate" on Sat, 18 Jul 2009 15:17:36 +0900, Yehuda Katz writes: |Very good keynote today. I enjoyed looking at some of the new features you |are playing around with. I was very existed about lvar_propagate, and am |hoping I can convince you to give it another chance :) | |Here's why: In my ideal world, blocks behave transparently to the end user. |There would be no difference between: In my ideal world, there's no implicit block-local variable, just flat to innermost scope making construct, e.g. def, class, module etc. And when one want block-local variables, he need to declare them by using block local variable list in the block parameter part (|a; b c|), or by using := assignment from block_local_vars_eq patch stack, which was also in the keynote. 100.times do |x| v1 = x v2 := x ... end p v1 # local variable; no block scope p v2 # name error; out of scope In real world, It would cause serious compatibility problem. That's the very reason I made up far more complex local variable propagation. Shugo came to me today telling me he made a patch to realize flat local variable scope that can be enabled by magic comment, so that 100.times do |x| v1 = x ... end p v2 # name error; out of scope But if there's a magic comment # -*- nested-local-variables: false -*- 100.times do |x| v1 = x ... end p v2 # local variable; no block scope I have not yet have any conclusion about the idea, but eventual migration using magic comment may be realistic (or not). I am not sure which is the best way from: * keeping as they are. no compatibility issue. * local variable propagation. complex, but works for most of the cases. little (if any) compatibility issue. * flat local variable scope, unless explicitly declared. has compatibility issue. need migration path. matz.