D/Objective-C Preliminary Design

[Michel Fortin]

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.

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.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/