< :前の番号
^ :番号順リスト
> :次の番号
P :前の記事
N :次の記事(自分と同じ返事先を持つ)
|<:スレッドの先頭
>|:次のスレッド
^ :返事先
_:自分への返事
>:同じ返事先を持つ記事(前)
<:同じ返事先を持つ記事(後)
---:分割してスレッド表示、再表示
| :分割して(縦)スレッド表示、再表示
~ :スレッドのフレーム消去
.:インデックス
..:インデックスのインデックス
On 2/28/08, Eero Saynatkari <ruby-ml / kittensoft.org> wrote:
> 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
Except, as I understand the discussion, here duck is a variable
representing the receiver of a message with an objective-c message
selector of foo:bar: and which in Ruby might be written as:
class PotentialClassOfDuck
def foo(first_arg, keywords={})
end
end
I think that a reasonable Ruby parser would have a hard time seeing:
duck foo: 1, bar: 2
as anything other that
self.duck(foo:1, foo:2)
So I think we'd need to give it some help and write:
duck.foo: 1, bar:2
which given optional parentheses might also be written(?):
duck.foo(: 1, bar: 2)
but I'm not happy with either of those for several hopefully obvious
reasons having to do with the dependence on the presence or absences
of easily misread punctuation and whitespace.
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/