On Thu, Feb 28, 2008 at 6:33 AM, Rick DeNatale <rick.denatale / gmail.com> wrote:
>
> On 2/27/08, Laurent Sansonetti <laurent.sansonetti / gmail.com> wrote:
>  > Hi,
>  >
>  >  I am honored to announce the beginning of the MacRuby project!
>  >
>  >  MacRuby is a version of Ruby that runs on top of Objective-C. More
>  >  precisely, MacRuby is currently a port of the Ruby 1.9 implementation
>  >  for the Objective-C runtime and garbage collector.
>  >
>  >  You can learn more about the project on its homepage:
>  >
>  >  http://trac.macosforge.org/projects/ruby/wiki/MacRuby
>  >
>  >  MacRuby is still extremely experimental, but a first release is
>  >  expected very soon.
>
>  Interesting stuff.
>
>  After reading some of the material on the macosforge wiki, I'm curious
>  about the keyed arguments design.
>
>  It sounds like if I invoke a method like this:
>
>     x.foo(1, bar: 2)
>
>  Then what happens is that this gets turned into an
>  Objective-C/Smalltalk syntax message selector of foo:bar:, but if I
>  use
>     x.foo(1, 2, bar: 3)
>
>  then it effectively uses a different selector and uses Ruby parameter
>  semantics with bar: 3 getting mapped into {:bar => 3} the way Ruby 1.9
>  does it.
>
>  So what happens if I write a ruby class like this:
>
>  class C
>    def foo(*a)
>         keywords = a.pop if Hash === a.last
>         ...
>    end
>  end
>
>  And then, possibly in a separate file, write
>
>  def quack(duck)  # duck might be an instance of C, but is it?
>     duck.foo(1, 2, bar: 3)  # I guess this would work in any case.

True.

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

>  This also seems to be treading on some of the territory which Matz has
>  indicated he plans to be defining in Ruby 2.0.  I'm worried that
>  there's a fork down the road here.

I don't really see this as a fork, but more as a port. Most of MacRuby
is based on 1.9, because we want to use all the upstream code base. We
just use Objective-C when it's necessary to provide a tighter
integration with Mac OS X APIs. Because we want people to use Ruby to
write complete full Mac OS X applications, without paying the bridging
cost.

Laurent