On 2010-11-03 18:40:36 -0400, Walter Bright <[email protected]> said:
Michel Fortin wrote:
On 2010-11-03 13:55:35 -0400, Walter Bright <[email protected]> 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.
To be frank, I prefer even the underscore syntax... and the above is
full of syntactic ambiguities.
But the issue isn't the underscore, it's the verbosity of Objective-C
method names. Method names in Objective-C tend to be long and
expressive, they are meant to have the arguments interleaved between
each part of the selector. This interleaving makes Objective-C code
very natural to read. Remove that and you've got something that doesn't
read well and on top of that looks out of place in a D program.
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.
I think you've just lost one convert then... because I just got this
comment on my blog:
"""
Very promising!
This would be the incentive I need to write my first Cocoa program…
alone the simple feature of function overloading makes a world of
difference.
/Daniel
"""
You heard that right: someone is considering writing Cocoa programs
because of D!
I think we should try to attract Cocoa programmers (and would-be Cocoa
programmers) by offering them the strengths of D. What are those
strengths? Some are things you probably take for given (overloading),
others are design by contract, generic programming, nested classes,
mixins, integrated unittests and documentation, memory safety, a
race-free threading model, did I miss anything? All those good things
aren't available in Objective-C and thus can't be used with Cocoa. I
want to make those them available to Cocoa programmers. And for this, I
need them to work with the Objective-C object model. By making
Objective-C objects bind to D semantics, all those feature will "just
work" with Cocoa with minimal changes to the frontend (and well written
bindings).
--
Michel Fortin
[email protected]
http://michelf.com/
