From: shevegen@... Date: 2018-11-06T14:15:03+00:00 Subject: [ruby-core:89723] [Ruby trunk Feature#4475] default variable name for parameter Issue #4475 has been updated by shevegen (Robert A. Heiler). I also like the idea in principle, largely because I can relate to it. For example consider code like this: object_that_responds_to_each.each {|x| object_that_responds_to_each.each {|this_file| Both variants essentially do the same here, e. g. we iterate over a collection, and we refer to the content. In the first case, I use x as name; in the second, I use the longer this_file. The second variant is a bit more understandable, I think, e. g. if we iterate over the content of a directory, such as vir Dir['*'] or something like that. The first variant, however had, is something I use A LOT, and the reason is actually because it is shorter and simpler to type. There are trade-offs between readability and ease-of-use, and since I am quite a lazy person, I often use the first variant. (I do so less when there is more than one block parameter, but sometimes I do too, such as via **iterator.each {|a, b, c, d] }** ). Matz said that compatibility is an issue, but if we ignore this for the moment, I really think that the proposal is a very interesting one. So I support the idea behind the suggestion. As for the specific syntax change such as in: Account.all.each { |a| my_account << a.money } Account.all.each { my_account << it.money } I have no particular pro or con opinion. I think the first variant, while longer, is more explicit; in the second variant there is a bit more "magic", unless we know that "it" would refer to the first block parameter. I am not sure if "it" is the ideal name, but I think the idea has merits on its own, irrespective of which name is chosen. (May have to be some special object perhaps, that is like an array, so we could do ... it[0] it[1] too... and perhaps also it.method_call_here, but again, these are mostly specifics I think.) Also I would like to mention that in the much longer case, such as this one here: object_that_responds_to_each.each {|this_file| I may have more variables like: object_that_responds_to_each.each {|this_file, that_directory, that_thing| And previously I also wanted a programmable way to refer to the first, second, and third block parameter, something short like the regex $1, $2, $3, which are one of the few global variables I like and use, since it is so trivial to refer to them. I also wanted to have this for block parameters, but I was unable to come up with a good syntax proposal. (All proposals should ideally be short, because if they are long then they have a smaller net benefit.) Anyway, apologies for the length of my comment; I think the idea is a good one. If it can not happen before ruby 3.x, perhaps we can aim for it in a long path towards ruby 4.x (if we can have more incompatibilites along the way). ---------------------------------------- Feature #4475: default variable name for parameter https://bugs.ruby-lang.org/issues/4475#change-74766 * Author: jordi (jordi polo) * Status: Assigned * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) * Target version: ---------------------------------------- =begin There is a very common pattern in Ruby: object.method do |variable_name| variable_name doing something end Many times in fact the name of the object is so self explanatory that we don't care about the name of the variable of the block. It is common to see things like : @my_sons.each { |s| s.sell_to_someone } or Account.all.each { |a| my_account << a.money } People tend to choose s or a because we have the class or the object name just there to remind you about the context. I would like to know if can be a good idea to have a default name for that parameter. I think it is Groovy that does something like: Account.all.each { my_account << it.money } Where it is automagically filled and it doesn't need to be declared. I think it is as readable or more (for newbies who don't know what is ||) and we save some typing :) =end -- https://bugs.ruby-lang.org/ Unsubscribe: