Re: MacRuby

On 2/27/08, Laurent Sansonetti <laurent.sansonettigmail.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.
    duck.foo(1, bar: 2)      #  mapped to foo:bar: what does
an
instance of C do with this?
end

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.

-- 
Rick DeNatale

My blog on Ruby
http://talklikead
uck.denhaven2.com/

On Thu, Feb 28, 2008 at 6:33 AM, Rick DeNatale
<rick.denatalegmail.com> wrote:
>
> On 2/27/08, Laurent Sansonetti
<laurent.sansonettigmail.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