From: Richard Kilmer <rich@...>
Date: 2008-02-29T10:42:09+09:00
Subject: Re: [ANN] MacRuby


On Feb 28, 2008, at 7:44 PM, Evan Phoenix wrote:

>
> On Feb 28, 2008, at 3:04 PM, Laurent Sansonetti wrote:
>
>> On Thu, Feb 28, 2008 at 1:51 PM, Yukihiro Matsumoto <matz@ruby-lang.org 
>> > wrote:
>>> Hi,
>>>
>>> In message "Re: [ANN] MacRuby"
>>>
>>>   on Fri, 29 Feb 2008 05:56:41 +0900, "Laurent Sansonetti" <laurent.sansonetti@gmail.com 
>>> > 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.

So in your view:

	O[duck foo:1, bar:2]

is elegant?  Elegant Ruby? no.  I agree to opt for the elegant syntax  
and that's:

  	duck foo:1, bar:2


>
>
> 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."

The method names are not radically different all the time:

window.frame #=> NSRect

In addition, what happens when you subclass?

class MyView < NSView
   def do_something_wonderful
   end
end

Now I have an instance:

view = MyView.alloc.init

call a Ruby method and then an objc method

view.do_something_wonderful
frame = O[view frame]

I find that visually scary.

I think the point here is to actually unify things if possible in a  
Ruby friendly way and that would be:

view.do_something_wonderful
frame = view.frame

>
>
> 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?

Yes, you can go the other way.

>
>
> - 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
>>
>
>