D/Objective-C Preliminary Design

[Michel Fortin]

On 2010-11-03 18:40:36 -0400, Walter Bright <newshound2 at digitalmars.com> said:

> 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.

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
michel.fortin at michelf.com
http://michelf.com/