The following code shows that: in Ruby, a method and a variable can share the same name in the same scope. If doing so, the Ruby intepreter will parse the name as variable, unless some explict method call sign is following:
Method call argument(s).
In Ruby code, you can see some ODD methods like Array’s “=” and “<<”. which you don’t have to use the “dot” manner to call, but an operator way instead:
a = [1, 2, 3]
But for a normal method, you cannot call it in the operator way. This confuse me. What kind of methods can be called as the operator way, why the other methods cannot?
From “Alberto Moriconi”:
Ruby also allows to define operators using the operator symbol as the method name:
Unary operator methods are passed no arguments; binary operator methods are passed an argument, and operate on it and on self.
It’s important to adhere strictly to the arity of the operators; while it is possible to define operator methods with a different arity (e.g. a + method that takes two arguments), Ruby would not allow you to call the method with operator syntax (it would however work with dot syntax).
It’s good practice to adhere to the original semantics of the operators as much as possible: it should be intuitive to someone who knows the original meaning of the operator how it works with user defined classes.
The language also offers syntactic sugar for the special, non-operator , method that is normally used for accessing array and hash values. The  method can be defined with arbitrary arity.
For every binary operator in the table, except ordering, equality, comparison and pattern matching, Ruby also offers shorthand for abbreviated assignment (e.g. x += y expands to x = x + y); you can’t define them as methods, but you can alter their behavior defining the operators on which they’re based.
From “Jörg W Mittag”:
There is no particular reason why Ruby couldn’t support user-defined operators in a style similar to Scala. There is a reason why Ruby can’t support arbitrary methods in operator position, simply because
foo plus bar
is already legal, and thus this would be a backwards-incompatible change.
Another thing to consider is that Ruby wasn’t actually fully designed in advance. It was designed through its implementation. Which means that in a lot of places, the implementation is leaking through. For example, there is absolutely no logical reason why
is legal but
isn’t. The only reason why this is so, is because Matz used an LALR(1) parser to parse a non-LALR(1) language. If he had designed the language first, he would have never picked an LALR(1) parser in the first place, and the expression would be legal.
The Refinement feature currently being discussed on ruby-core is another example. The way it is currently specified, will make it impossible to optimize method calls and inline methods, even if the program in question doesn’t actually use Refinements at all. With just a simple tweak, it can be just as expressive and powerful, and ensure that the pessimization cost is only incurred for scopes that actually use Refinements. Apparently, the sole reason why it was specified this way, is that a) it was easier to prototype this way, and b) YARV doesn’t have an optimizer, so nobody even bothered to think about the implications (well, nobody except Charles Oliver Nutter).
So, for basically any question you have about Ruby’s design, the answer will almost always be either “because Matz said so” or “because in 1993 it was easier to implement that way”.