Re: [ANN] MacRuby

On Feb 28, 2008, at 3:04 PM, Laurent Sansonetti wrote:

> On Thu, Feb 28, 2008 at 1:51 PM, Yukihiro Matsumoto <[e-mail] 
> > wrote:
>> Hi,
>>
>> In message "Re: [ANN] MacRuby"
>>
>>    on Fri, 29 Feb 2008 05:56:41 +0900, "Laurent Sansonetti" <[e-mail] 
>> > writes:
>>
>> |>     duck.foo(1, bar: 2)      #  mapped to foo:bar: what does an
>> |>  instance of C do with this?
>> |
>> |Here, MacRuby will check if duck responds to foo:bar:. If true, this
>> |message is sent with 1 and 2 as arguments. If not true, the foo
>> |message is sent instead with 1 and {:bar => 2} as arguments.
>> |
>> |If you're working with pure Ruby objects, the second code path  
>> should
>> |always be taken. Unless you define foo:bar: in your Ruby class.
>> |
>> |Note that the key:value syntax to describe a hash pair is  
>> available in
>> |vanilla 1.9.
>>
>> I still think having dedicated syntax for Objective-C call is better
>> than overriding normal call.
>>
>>
>>  duck.foo: 1 bar: 2
>>
>> or
>>
>>
>>  duck.foo: 1, bar: 2
>>
>> maybe?  I am not sure if the parser allows this or not yet.
>>
>

I thought about working up for Objective-C calling support via this  
syntax:

O[duck :foo => 1, :bar => 2]

At one point, I had a small parser change that allowed this to be  
written as:

O[duck foo: 1, bar: 2]

The idea was that the rubinius compiler would detect this special form  
and emit the 'right thing'.

I think a bit part of this is whether you expect users (and other  
code) to know they're calling out to Objective-C, or if you want tight  
integration. This is essential what matz says.

By making special Objective-C syntax, then you can't pass in an  
Objective-C object and expect it to be duck-typed like normal ruby  
objects. But the trade off is that the syntax is less elegant. I think  
it's a trade off, and my 2 cents is you should opt for the more  
elegant syntax. This is because there are only a few tiny edge cases  
where the Objective-C selector matches the ruby selector, where you'd  
want to allow the ObjC object to be duck typed as something else.

Thus, since the method names are so radically different, it's better  
that the user know "ok, I'm calling this other kind of method, so I  
need to use this syntax."

If they want to duck-type it, then let them write a wrapper for the  
ObjC method/syntax:

def call_objc(a, b)
   O[duck foo: a, bar: b]
end

Something else that has not been brought up (that I saw) is whether  
ruby methods are available as Objective-C methods. Can ruby methods be  
called directly via the ObjC runtime?

  - Evan

> I have been thinking about this too, but I personally believe that it
> doesn't reveal very pretty when messaging Objective-C methods with
> only one argument.
>
>  duck.foo: 1
>
> But maybe we will switch to it soon, because it's more consistent with
> Objective-C (no potential ambiguities). But it doesn't feel very Ruby.
>
> Laurent
>