On 13.10.2007 19:43, Rick DeNatale wrote:
> On 10/12/07, Arlen Christian Mart Cuss <celtic / sairyx.org> wrote:
>> Hi,
>>
>> On Fri, 2007-10-12 at 14:39 +0900, John Woods wrote:
>>> I'm trying to redefine the >> operator for a particular class such that
>>> it takes a block as its argument. It works if I invoke the redifined >>
>>> operator using "." syntax, but causes a syntax error otherwise.
>> I think the problem is summed up shortly in another reply, but --
>>
>>>> is a binary operator, meaning it must accept one argument. Block
>> arguments are treated in a special manner (e.g. the arity of a method
>> which takes only a block is 0), and thus aren't valid as the other
>> operand of a binary operator!
> 
> Note from the post which started this thread:
> 
> c.>> { |x| puts x } # outputs "inside >>"
> #c >> { |x| puts x } # syntax error, if uncommented
> 
> It really doesn't have to do with the arity of the method.   It's the
> way the statement is parsed, the parser doesn't check arity, in fact I
> don't think it could if it wanted to, it doesn't know what method
> would be bound to :>> for an arbitrary value of c.
> 
> That '.' on the first line makes all the difference, The c >> x is
> syntactic sugar for sure which the parser turns into what gets
> evaluated effectively as c.>>(x)  but since the parser doesn't see a
> valid x it results in a syntax error.

Yeah, and that's why operators are special in a way when it comes to 
arity.  Although you can define them with arbitrary arity the normal 
usage of a binary operator enforces exactly one argument (plus self of 
course) and thus practically enforces arity one - even if you can pass 
more arguments when using dot notation.


irb(main):001:0> def +(*a)p a end
=> nil
irb(main):002:0> self.+ 1,2,3
[1, 2, 3]
=> nil
irb(main):003:0> self + 1
[1]
=> nil

Kind regards

	robert