From: Benoit Daloze <eregontp@...>
Date: 2010-04-18T23:10:26+09:00
Subject: [ruby-core:29598] Re: [Bug #3163] SyntaxError when using variable 	which is also a method in current scope with a Symbol argument

--0016e659fb44ba6e34048483672a
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

>as in a ? b : c.
Oups, I always forget that one. But to my defense it's only an operator if
preceded by ?

On 18 April 2010 07:44, Kornelius Kalnbach <murphy@rubychan.de> wrote:

> On 17.04.10 20:26, Benoit Daloze wrote:
> > I ran a few times in this bug, while using some "p :done"(and having
> > a local var p) to trace the program execution quickly.
> Translated into a Ruby style guide haiku:
>
>  Never use p
>  As a local variable;
>  It breaks.
>
> [murphy]
>
>
Sure, but that's why I showed that any variable which is also a method in a
scope can cause this problem.
That's right, I should really not use p, it's just because that's what
happened to me most of the time.

class Foo
  def bar(*args)
    :bar
  end

  def main
    bar =3D 2
    # ...
    bar my: "hash"
  end
end
Foo.new.main

I myself agree it's often not a good idea to name a variable with the name
of a method you will use there without () and with an argument like a
literal Symbol/Hash. And the names of the methods usually are not
appropriate for the name of a variable.

But, it's not because this shouldn't appear too much it shouldn't be fixed.

Also in this case, the error is very disturbing:
> p =3D 0; p %Q{a}
NoMethodError: undefined method `Q' for main:Object

Let's take your examples:
p =3D 0
p %[foo]
p /foo/x
p &foo
p *foo
p ?f : g
p <<foo

They are all raising "NameError: undefined local variable or method =91foo=
=92
for main:Object" except the one with the ternary condition.

I think in all these cases, it should be considered as an operator only if
there is a space after, because you use a space before.
If there is no space, then it should be an operator.
If there is more spaces at left than right of the 'operator' it should be a
method.
p % [a] # operator
p %[a] # method
p%[a] # operator

This idea is valid only if the right part is a literal expression:
p % a , p %a , p%a are in all cases operators.

Would it be possible to implement a rule like that:
"if more spaces at left than right and right is a literal expression,
consider left as a method" (instead of always as an operator)

Are you thinking the same way to consider theses expressions ?

This change is only an improvement to my opinion, so I don't see when it ca=
n
cause problems.

And the most important, thank you, Nobu, for resolving the main issue of
this bug :)

--0016e659fb44ba6e34048483672a
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">&gt;as in a ? b : c.<br>Oups, I always forget th=
at one. But to my defense it&#39;s only an operator if preceded by ?<br><br=
>On 18 April 2010 07:44, Kornelius Kalnbach <span dir=3D"ltr">&lt;<a href=
=3D"mailto:murphy@rubychan.de" target=3D"_blank">murphy@rubychan.de</a>&gt;=
</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>On 17.04.10 =
20:26, Benoit Daloze wrote:<br>
&gt; I ran a few times in this bug, while using some &quot;p :done&quot;(an=
d having<br>
&gt; a local var p) to trace the program execution quickly.<br>
</div>Translated into a Ruby style guide haiku:<br>
<br>
 =A0Never use p<br>
 =A0As a local variable;<br>
 =A0It breaks.<br>
<br>
[murphy]<br>
<br></blockquote><div>=A0</div></div>Sure, but that&#39;s why I showed that=
 any variable which is also a method in a scope can cause this problem.<br>=
That&#39;s right, I should really not use p, it&#39;s just because that&#39=
;s what happened to me most of the time.<br>


<br>class Foo<br>=A0 def bar(*args)<br>=A0=A0=A0 :bar<br>=A0 end<br>=A0 <br=
>=A0 def main<br>=A0=A0=A0 bar =3D 2<br>=A0=A0=A0 # ...<br>=A0=A0=A0 bar my=
: &quot;hash&quot;<br>=A0 end<br>end<br>Foo.new.main<br><br>I myself agree =
it&#39;s often not a good idea to name a variable with the name of a method=
 you will use there without () and with an argument like a literal Symbol/H=
ash. And the names of the methods usually are not appropriate for the name =
of a variable.<br>


<br>But, it&#39;s not because this shouldn&#39;t appear too much it shouldn=
&#39;t be fixed.<br><br>Also in this case, the error is very disturbing:<br=
>&gt; p =3D 0; p %Q{a}<br>NoMethodError: undefined method `Q&#39; for main:=
Object<br>


<br>Let&#39;s take your examples:<br>p =3D 0<br>p %[foo]<br>p /foo/x<br>p &=
amp;foo<br>p *foo<br>p ?f : g<br>p &lt;&lt;foo<br><br>They are all raising =
&quot;NameError: undefined local variable or method =91foo=92 for main:Obje=
ct&quot; except the one with the ternary condition.<br>


<br>I think in all these cases, it should be considered as an operator only=
 if there is a space after, because you use a space before.<br>If there is =
no space, then it should be an operator.<br>If there is more spaces at left=
 than right of the &#39;operator&#39; it should be a method.<br>


p % [a] # operator<br>p %[a] # method<br>p%[a] # operator<br><br>This idea =
is valid only if the right part is a literal expression:<br>p % a , p %a , =
p%a are in all cases operators.<br><br>Would it be possible to implement a =
rule like that:<br>


&quot;if more spaces at left than right and right is a literal expression, =
consider left as a method&quot; (instead of always as an operator)<br><br>A=
re you thinking the same way to consider theses expressions ?<br><br>This c=
hange is only an improvement to my opinion, so I don&#39;t see when it can =
cause problems.<br>


<br>And the most important, thank you, Nobu, for resolving the main issue o=
f this bug :)<br>

--0016e659fb44ba6e34048483672a--