[ruby-core:29598] Re: [Bug #3163] SyntaxError when using variable which is also a method in current scope with a Symbol argument

>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 <[e-mail]> 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 = 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 = 0; p %Q{a}
NoMethodError: undefined method `Q' for main:Object

Let's take your examples:
p = 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 素oo
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 can
cause problems.

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