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: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>