From: Matthew Kerwin Date: 2014-01-20T10:19:03+10:00 Subject: [ruby-core:59878] Re: [ruby-trunk - Feature #9428] Inline argument expressions and re-assignment --001a11c36c50d654a104f05bd6ae Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm -1 for this. 1. aesthetically: it puts some of the function's code outside the function's body, which makes it harder to follow a function's execution when reading code, and it makes the signature unnecessarily messy. 2. syntactically: none of the proposals you've given make enough sense, at least for me personally to understand what they mean: def foo( arg.to_i ) def foo( arg.to_i as arg ) Is the left-most 'arg' a local variable, or referring to self#arg, or something else..? > Ruby could auto-assign the passed argument to the first variable encountered in the expression. According to my understanding of the parser, any heretofore unseen "bareword" tokens are interpreted as function calls, so there is no "first variable encountered." It works for optional positional parameters because they have an equals sign in (and 'bareword =3D expression' is universally lvar creation/assignment, in Ruby). 3. debugability: the 'def' line is a single line, however there's no real limit to the number of parameters you can include in that line. If each of those parameters can include arbitrary expressions, well, I'd hate to have to debug a "NoMethodError: undefined method ... for nil:NilClass" on that line. And if the answer to that is to split the 'def' line over multiple lines, then why not just put the expressions on those multiple lines anyway= ? 4. orthogonality: what about non-optional keyword arguments? For what it's worth, I'm not entirely *for* allowing arbitrary expressions in optional parameters either, but in that case I can't think of a better representation. But if I ever seen anything more than a #[] call in a default value I consider it Bad Form=99. --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a11c36c50d654a104f05bd6ae Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I'm -1 for this.

1. aesthetically: it puts some of the function's code outside the funct= ion's body, which makes it harder to follow a function's execution = when reading code, and it makes the signature unnecessarily messy.

2. syntactically: none of the proposals you'= ;ve given make enough sense, at least for me personally to understand what = they mean:

=A0 def foo( arg.to_i )

=A0 def foo( arg.to_i as arg )

Is the left= -most 'arg' a local variable, or referring to self#arg, or somethin= g else..?

>=A0Ruby could auto-assign the passed a= rgument to the first variable encountered in the expression.

According to my understanding of the parser, an= y heretofore unseen "bareword" tokens are interpreted as function= calls, so there is no "first variable encountered." =A0It works = for optional positional parameters because they have an equals sign in (and= 'bareword =3D expression' is universally lvar creation/assignment,= in Ruby).

3. debugability: the 'def' line is a si= ngle line, however there's no real limit to the number of parameters yo= u can include in that line. =A0If each of those parameters can include arbi= trary expressions, well, I'd hate to have to debug a "NoMethodErro= r: undefined method ... for nil:NilClass" on that line. =A0And if the = answer to that is to split the 'def' line over multiple lines, then= why not just put the expressions on those multiple lines anyway?

4. orthogonality: what about non-optional keywo= rd arguments?

For what it's worth, I'm not entirely *= for* allowing arbitrary expressions in optional parameters either, but in t= hat case I can't think of a better representation. =A0But if I ever see= n anything more than a #[] call in a default value I consider it Bad Form= =99.

=A0 Matth= ew Kerwin
=A0 http://matthew.kerwin.net.au/

--001a11c36c50d654a104f05bd6ae--