On 2010-11-03 13:55:35 -0400, Walter Bright <newshou...@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.for...@michelf.com
http://michelf.com/
