On 28 Sep 2006, at 15:00, Hal Fulton wrote:

> Eero Saynatkari wrote:
>> On 2006.09.28 14:32, Hal Fulton wrote:
>>> Eero Saynatkari wrote:
>>>
>>>> I would go so far as saying that the standard Ruby syntax for  
>>>> this is
>>>>
>>>> foo.x y, z
>>>
>>> I don't know what you mean. That is not valid in Ruby (unless
>>> x is a singleton method). In particular it doesn't work if
>>> foo.x is a Proc, which is the situation discussed.
>> It is valid if x is a method that foo responds to.
>> Storing callable objects seems not a very rubyesque
>> thing to do--albeit necessary on occasion. In lieu
>> of worrying about keeping interface compatibility
>> with Python, I would recommend the OP merely make
>> the API as idiomatic Ruby as possible.
>
> I think he was merely striving to keep the code
> intuitive, not striving for compatibility with
> Python as such. I concur with his desire for
> intuitiveness (and I concur with your statement
> that he should stick to idiomatic Ruby when
> writing Ruby).

Indeed. I am 99% certain that the

foo['x'].call(y,z)

syntax is best here, since it is more familiar for Ruby programmers  
(and there are a lot more Ruby programmers than RPy programmers).  
This is only for edge cases anyway, most of the time the more  
intuitive form can be used:

foo.x(y,z)

and some method_missing magic will be used. The only trouble is that  
R has a few methods such as '$' and even '[[' which require this work  
around to be able to call. I'm sure

foo.[[(y.z)

can never be made into valid Ruby, but

foo['[['].call(y,z)

while hideous, is at least valid syntax.

> As for storing callable objects -- in general this
> is not an unrubyish practice if done properly; it's
> just slightly advanced. Nothing done properly is
> unrubyish. ;)

I will endeavour to do it properly. ;)

> The apparent inconsistency of foo[x] or foo.call(x)
> stems partly from the fact that Ruby does not require
> declarations as such.
>
> If foo were a Proc and we called it the "intuitive"
> way -- foo() -- it would look just like a method call.
> This is good for readability in a way, but bad in that
> we lose part of the disambiguation. Ruby is happy to
> have a local variable foo and a method foo in the same
> scope (though naturally I don't recommend it).

Yes, a quick test with Python shows the difference between it and  
Ruby in this respect (which I'd never really though about before):

Python 2.3.5 (#1, May 31 2005, 16:03:09)
 >>> foo=5
 >>> def foo():
...     return
...
 >>> print foo
<function foo at 0x444c70>

Compared to:

irb(main):001:0> foo=5
=> 5
irb(main):002:0> def foo() return end
=> nil
irb(main):004:0> puts foo
5
=> nil

Dr Alex Gutteridge
Post-Doctoral Researcher

Bioinformatics Center
Institute for Chemical Research
Kyoto University
Gokasho, Uji, Kyoto 611-0011
Japan