Re: MacRuby

Hi,

In message "Re: [ANN] MacRuby"
    on Fri, 29 Feb 2008 08:04:38 +0900, "Laurent
Sansonetti" <laurent.sansonettigmail.com> writes:

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

You can still map one-argument method to duck.foo(1) as it
does now.

|But maybe we will switch to it soon, because it's more
consistent with
bjective-
C (no potential ambiguities). But it doesn't feel very
Ruby.

That is very important design decision.  Objective-C-ish
calling or
Ruby-ish calling.  The latter makes program consistent, but
the former
makes program obvious. Hmm.

							matz.

On Thu, Feb 28, 2008 at 3:15 PM, Yukihiro Matsumoto
<matzruby-lang.org> wrote:
> Hi,
>
>  In message "Re: [ANN] MacRuby"
>
>     on Fri, 29 Feb 2008 08:04:38 +0900, "Laurent
Sansonetti" <laurent.sansonettigmail.com> writes:
>
>  |>  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 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
>
>  You can still map one-argument method to duck.foo(1)
as it does now.
>

Yes, but it won't be consistent with multiple-argument calls
then.

>  |But maybe we will switch to it soon, because it's
more consistent with
>  bjective-
C (no potential ambiguities). But it doesn't feel very
Ruby.
>
>  That is very important design decision. 
Objective-C-ish calling or
>  Ruby-ish calling.  The latter makes program
consistent, but the former
>  makes program obvious. Hmm.
>

Definitely! I have been thinking about this a lot, but I
couldn't come
with something better than what's currently in MacRuby.

duck.foo               # may call foo
duck.foo(1)           # may call foo:
duck.foo(1, key:2) # may call foo:key:

There is also the problem of defining methods with keyed
arguments. Currently:

def foo(x, key:y); end # will register foo:key:

Laurent

On 2008.02.29 08:15, Yukihiro Matsumoto wrote:
> That is very important design decision. 
Objective-C-ish calling or
> Ruby-ish calling.  The latter makes program consistent,
but the former
> makes program obvious. Hmm.

Actually, this would be a really great time to talk about
trying to unify
the keyword argument syntax across implementations so that
we do not have
to have that discussion later or contend with several
variants. I know that
we are not at the 2.0 threshold yet, but obviously folks are
starting to
get there.

In the particular case of MacRuby, I would go for
implicitness unless
there is a reason that the programmer needs to know the
difference. If
we can define an official syntax (and semantics) for keyword
arguments
that also helps MacRuby, I think that would be the optimal
solution.

I would probably prefer one of the Smalltalkish variants as
the standard:

  duck foo: 1, bar: 2

This plausibly conforms to current method semantics:

  def duck(**kwargs)              # Implicit in the vcall
    sym, arg = kwargs.shift
    __send__ sym, arg, **kwargs
  end


--
Eero