Laurent Sansonetti
lsans****@apple*****
Mon Jun 19 23:46:04 JST 2006
On Jun 19, 2006, at 4:29 PM, kimura wataru wrote: > Hi, > > On Mon, 19 Jun 2006 14:25:12 +0200, Laurent Sansonetti wrote: >> Hi all, >> >> I recently had a long discussion with colleagues (that are using >> PyObjC) about the current messages dispatchers in RubyCocoa. You >> know that right now you can do: >> >> 1/ obj.aaa_bbb_(123, 456) >> 2/ obj.aaa_bbb(123, 456) >> 3/ obj.aaa(123, :bbb, 456) >> 4/ obj.aaa(123, :bbb => 456) # only in the unstable branch >> >> One of the problems about 2/ 3/ and 4/ is that they can lead to >> ambiguities in (very rare) cases [1]. Some people are afraid about >> this, and would prefer to see only 1/ supported. I did my best to >> defend the current syntaxes... >> > > I prefer 2/ rather than 1/. 1/ is ugly. > Me too! :-( >> [1]: >> >> Omitting the trailing underscore can lead to confusions, for ex: >> >> [MyClass +foo] >> [MyClass +foo:(id)foo] >> >> Calling MyClass.foo() can be ambiguous for the user, which method is >> he calling? Basing on the given number of arguments is also >> ambiguous, we could pass an exploded array (*[]) and we would call >> different methods based on the array value. >> > > An ObjC method that takes variable number of arguments requires one > argument at least to know the number of arguments. All of Cocoa > variadic > methods belong to either of the following types. > > (A)format string (such as [NSPredicate predicateWithFormat:]) > needs format string for first argument > (B)array of values (such as [NSArray arrayWithObjects:]) > needs nil for last argument > > So I believe that 2/ works without any problem. [snip] Yes I agree with you, but this is not about variable arguments here. Imagine you have this in Objective-C: [MyClass +foo] [MyClass +foo:(id)foo] If in Ruby you call: MyClass.foo() Which method will it call, as passing nil is supported? In that case, if you want to be sure to reach [MyClass +foo:(id)foo] you need to explicitely append '_': MyClass.foo_() I totally understand that this is a very rare case, and that is most cases omitting the '_' is OK. But some people here would like to avoid these very rare cases. They want to support a full stable bridge. It seems that PyObjC tried to remove the '_' but each time they put it again, for some valuable reasons. Here is a bunch of links from a recent conversation: http://mail.python.org/pipermail/pythonmac-sig/2002-October/006485.html http://mail.python.org/pipermail/pythonmac-sig/2002-October/006488.html http://mail.python.org/pipermail/pythonmac-sig/2002-October/006465.html http://mail.python.org/pipermail/pythonmac-sig/2002-October/006480.html We will provide documentation for this new flag, and we will describe all potential ambiguous cases to warn the developers. People that know what they are doing would just have to do: OSX.friendly_syntax = yes # or whatever flag name At the beginning of their Ruby main script. If you have another ideas/arguments do not hesitate. Laurent
