Laurent Sansonetti
lsans****@apple*****
Tue Jun 20 10:10:33 JST 2006
On Jun 19, 2006, at 7:22 PM, Jonathan Paisley wrote:
>
>>
>> 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?
>
> I'm confused - I don't think we assume anywhere that omitting an
> argument is the same as passing nil.
>
> In other words, MyClass.foo() should never call the foo: method,
> because that would involve assuming that you want to pass nil. We
> have not given any arguments, therefore it can only call an objc
> method that takes no arguments.
>
You're absolutely right, I just checked this now. Sorry this point is
void, let's forget it, I should really take some vacation :-)
Actually, calling
foo_()
Will call foo: with nil, but this is another story.
> The point you made in your first message about exploded arrays also
> doesn't appear to apply, because an exploded empty array is
> equivalent to a method call with no arguments.
>
> i.e.,
> x.foo(*[])
> is the same as
> x.foo()
> (I think).
Yes, however:
a = []
# Conditionally fill `a' with some value
x.foo(*a)
Could end up calling different methods, according to the content of `a'.
We had a long discussion internally, and here is a quick copy/paste
summary. Given that you can do:
(1) url1 = NSURL.alloc.initWithScheme_host_path('http',
'localhost', '/foo')
(2) url2 = NSURL.alloc.initWithScheme('http', :host,
'localhost', :path, '/foo')
(3) url3 = NSURL.alloc.initWithScheme('http', :host =>
'localhost', :path => '/foo')
The problems are:
(1) While the dropping of the '_' on the end is a nice convenience
mechanism, it can lead to unexpected and difficult to deduce bugs.
While you can disambiguate between 'foo' and 'foo:' by counting
arguments for a static dispatch, this breaks down with dynamic
dispatch patterns that are common to scripting languages.
(2) This is changing the naming convention of the Objective-C
selector. No longer will the developer think "Oh, I'm calling
"initWithScheme:host:path:", now it is "I'm calling the
"initWithScheme method that has the 'host' and 'path' arguments.".
In other words, it is reinforcing the incorrect notion that Objective-
C has named arguments. This, in turn, causes no end of confusion
among the scripting confusion.
(3) Not only does this perpetuate the mistaken notion that ObjC has
named arguments, it also implies that argument order does not
matter. It causes even more confusion than (2) and it introduces
new failure modes that can be incredibly confusing and hard to debug.
Laurent
PS: If anyone is interested I can arrange a thread with those
internal people here.