Re: [ANN] MacRuby

On 2/28/08, Laurent Sansonetti <[e-mail]> wrote:

> The problems with these syntaxes are that it's hard to parse them, and
>  that they can lead to ambiguities when wrongly used.
>
>  For example,
>
>   duck.foo: x, with: y
>
>  could be written by mistake as
>
>   duck.foo :x, with: y
>
>>  which has a completely different meaning.
>
>  Also, when the parenthesizes are omitted, it may be hard to correctly
>  parse (assuming that you want to send the message to self)
>
>   foo:x, with:y
>
>  That's why I think that the following is the best compromise so far,
>  between readability and reliability.
>
>   foo x, with:y # or foo(x, with:y)

One thing that's yet to be mentioned is that the Ruby keyword
arguments are position independent so that using Ruby 1.9 semantics:

     foo(x, a: y, b: z)
and
    foo(x, b:z, a:y)

are equivalent, but in MacRuby, as I understand it they result in two
different message selectors foo:a:b: and foo:b:a: respectively.

I'm something which I didn't comment on in an earlier posting might
bear some discussion.

I'd posed a situation where a Ruby class had implemented a foo method
with ruby 1.9 handling of 'keyword' arguments via an optional hash as
the last argument of a *args. then asked

>>     duck.foo(1, bar: 2)      #  mapped to foo:bar: what does an
>>  instance of C do with this?

And Laurent responded:

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

I'm concerned here about the automatic 'chicken-type' and branch in
the caller, for the performance implications if nothing else.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/