Michel Fortin Wrote: > 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.
I like the way you've done it. It seems like the Obj-C approach is kind of a sneaky way of implementing function overloading in C. D supports overloading, so there's no point in creating function names that include parameter names simply to match the Obj-C definition. Instead, only the function name is carried through and the rest is dropped into the parameter list. It seems like this approach would be easy to automate anyway, and more readable than the long form.
