D/Objective-C Preliminary Design
Walter Bright
newshound2 at digitalmars.com
Wed Nov 3 15:40:36 PDT 2010
Michel Fortin wrote:
> On 2010-11-03 13:55:35 -0400, Walter Bright <newshound2 at digitalmars.com>
> said:
>
>> Thanks for doing this!
>
> You're welcome.
>
>
>> "To make Objective-C methods accessible to D programs, we need to map
>> them to a D function name. This is acomplished by declaring a member
>> function and giving it a selector:"
>>
>> Why not just make the D member function the selector name?
>
> The primary reason is that selectors have a different syntax than D
> identifiers (they often contain colons). We could add some sort of
> mapping, converting colons to underscores for instance, but that's not
> very clean and would be a little ugly. Let me show you why.
>
> Because in Objective-C arguments are interleaved inside the multi-part
> method name (the selector), it's deemed good there to have very
> expressive names. For instance, key-value-observing in Cocoa use this
> method selector:
>
> addObserver:forKeyPath:options:context:
>
> When you call this method in Objective-C, it's done like this:
>
> [o addObserver:self forKeyPath:@"window.frame" option:0 context:nil];
>
> Let's convert this in a D-compatible syntax by replacing colons by
> underscores:
>
> o.addObserver_forKeyPath_options_context_(this, "window.frame", 0,
> nil);
>
> Now imagine a whole program with functions like this one. Would you want
> to write a program like that? I'd surely like to hear other's opinions
> on that subject, but to me it seems to be a better idea to provide
> adapted function names.
How about a way to use . instead?
o.addObserver.forKeyPath.options.context(this, "window.frame", 0, nil);
That would fit right in with, say, forKeyPath being a "member" of addObserver.
> Another reason is that it allows Objective-C objects to behave more like
> normal D objects. Objective-C doesn't have overloading -- you can't have
> two methods with the same selector -- so overloading requires some kind
> of mapping between the selector and the D function name. And some
> algorithms might expect overloading, so having this capability improves
> interoperability. But this is more like a secondary benefit.
I would say, for extern(Objective-C) functions, simply disallow overloading.
More information about the Digitalmars-d
mailing list