Hello Michel,

> [o addObserver:self forKeyPath:@"window.frame" option:0 context:nil];
[...]
> Now imagine a whole program with functions like this one. Would you
> want to write a program like that?

I know, not what you were saying but, err,.. No.

Walter Bright:
>> 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).
>
>
> I don't know O-C. I've never written a line of it. So I'm shooting in
> the dark about the best way to attach it to D.
>
> I agree with all your goals.
>
> One possibility: simply adopt O-C syntax.

That is what Objective-C++ is doing (for C++).

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocCPlusPlus.html

--anders

Michel Fortin wrote:
> 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.

The JavaBridge had lots of those functions, while it was alive:

http://developer.apple.com/legacy/mac/library/documentation/Cocoa/Conceptual/Legacy/JavaBridge/JavaBridge.pdf

-(void)setObject:(id)anObject forKey:(id)aKey;

void setObjectForKey(Object anObject, Object aKey);

--anders

Sean Kelly Wrote:

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

I strongly agree with Sean, I like the current approach.

Paolo

On 2010-11-04 07:37:25 -0400, Kagamin <spam@here.lot> said:

> Do you require explicit selector declaration? I'm afraid, this will lead to a large duplication:
> 
> extern (Objective-C)
> class NSComboBox : NSTextField
> {
>     private void* _dataSource;
> 
>     void insertItemWithObjectValue(ObjcObject object, NSInteger atIndex) [insertItemWithObjectValue:atIndex:];
>     void insertItemWithObjectValue(ObjcObject object) [insertItemWithObjectValue:];
> }
> 
> comboBox.insertItemWithObjectValue(val, idx); // [comboBox insertItemWithObjectValue:val atIndex:idx]
> comboBox.insertItemWithObjectValue(val);      // [comboBox insertItemWithObjectValue:val]
> 
> compiler can build selector automatically from function signature.

More or less. You need to specify the selector explicitly only if you need the function to have specific selector. Otherwise the compiler will generate one for you.

The compiler-generated selector will ensure that function overloading works by adding the mangled parameter types. As an exception for @property setters, the compiler will convert function 'name' to selector 'setName:' which should make properties work with key-value coding. For @IBAction functions, it'll use directly the name of the function.

So you should rarely have to specify the selector unless you're writing bindings to existing Objective-C objects. And, hopefully, creating bindings can be automated.

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

On 2010-11-03 23:28:38 -0400, Jason House <jason.james.house@gmail.com> said:

> What's the minimal set of O-C integration that would make your work usable? I'd try to get that in early and incrementally improve functionality.

That's a tricky question that depends on what you mean by "usable". I'd say that supporting extern (Objective-C) classes and interfaces and constructors is the minimal functionality to make things usable. But is it acceptable to put into mainline DMD something that is scheduled to work differently once I implement the rest, such as the memory management section with automatic reference counting?

I'm know I should release things early to let those interested test it and give me some feedback (and create bindings), but I'm not sure whether it should be merged into the trunk so early. With Walter's permission, I could publish my git repository to let people peek at the code. I haven't done so before because it's a clone of the SVN repository and it contains the backend too, which is under a less open license.

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

On 2010-11-04 04:14:41 -0400, Anders F Björklund <afb@algonet.se> said:

> Michel Fortin wrote:
>> 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.
> 
> The JavaBridge had lots of those functions, while it was alive:
> 
> http://developer.apple.com/legacy/mac/library/documentation/Cocoa/Conceptual/Legacy/JavaBridge/JavaBridge.pdf

-(void)setObject:(id)anObject 
> 
> forKey:(id)aKey;
> 
> void setObjectForKey(Object anObject, Object aKey);

Well, if you read closely that document, you'll see that they map Java function names to selectors manually too. The Java classes are generated from .jobs files, and in a .jobs file you'll find mapping for selectors:

"""
selector
	Specifies any non-default mappings between Objective-C selectors and Java method names. (The default is to use the Objective-C name before the colon as the Java name.) These mappings apply to all classes. Note: Put all of the mappings under a single selector specification.

selector
	-defineClass:withName: = defineClassWithName
	-pathForResource:ofType: = pathForResourceType
"""

I think a similar approach should be taken for tools that create bindings. Which means that by default it picks the first part of the selector as the function's name, but if you defined a custom mapping then it'll use that instead.


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

On 2010-11-03 20:51:00 -0400, Walter Bright <newshound2@digitalmars.com> said:

> Michel Fortin wrote:
>> You heard that right: someone is considering writing Cocoa programs because of D!
> 
> That's great news!
> 
>> 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).
> 
> I don't know O-C. I've never written a line of it. So I'm shooting in the dark about the best way to attach it to D.
> 
> I agree with all your goals.
> 
> One possibility: simply adopt O-C syntax.

That indeed could work. There's effectively a case to be made that we could integrate Objective-C in D the same way it is integrated with C++ with Objective-C++ (two distinct syntaxes for two distinct object models). Existing Objective-C programmers will probably be more familiar with code written this way so there's no doubt some people would prefer that.

But there's also a lot of Cocoa programmers that would prefer a more "conventional" syntax and D could be very appealing to them. I'm not one of those as I'm quite fond of the long and expressive method names in Objective-C, but I still think it's a bad fit for D because it gets in the way of bringing those interesting D features to Cocoa.


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

Michel Fortin wrote:
>>> 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.
>>
>> The JavaBridge had lots of those functions, while it was alive:
>>
>> http://developer.apple.com/legacy/mac/library/documentation/Cocoa/Conceptual/Legacy/JavaBridge/JavaBridge.pdf
[...]
> I think a similar approach should be taken for tools that create
> bindings. Which means that by default it picks the first part of the
> selector as the function's name, but if you defined a custom mapping
> then it'll use that instead.

Sure, I just meant that it will still look long and out of place ?
Just like it did in Java... And that's probably saying something.
(Java wasn't exactly afraid of long-widing names in the first place)
One of the old favorites was addObjectToBothSidesOfRelationshipWithKey

--anders

On 2010-11-04 13:08, Michel Fortin wrote:
> On 2010-11-04 07:37:25 -0400, Kagamin <spam@here.lot> said:
>
>> Do you require explicit selector declaration? I'm afraid, this will
>> lead to a large duplication:
>>
>> extern (Objective-C)
>> class NSComboBox : NSTextField
>> {
>> private void* _dataSource;
>>
>> void insertItemWithObjectValue(ObjcObject object, NSInteger atIndex)
>> [insertItemWithObjectValue:atIndex:];
>> void insertItemWithObjectValue(ObjcObject object)
>> [insertItemWithObjectValue:];
>> }
>>
>> comboBox.insertItemWithObjectValue(val, idx); // [comboBox
>> insertItemWithObjectValue:val atIndex:idx]
>> comboBox.insertItemWithObjectValue(val); // [comboBox
>> insertItemWithObjectValue:val]
>>
>> compiler can build selector automatically from function signature.
>
> More or less. You need to specify the selector explicitly only if you
> need the function to have specific selector. Otherwise the compiler will
> generate one for you.
>
> The compiler-generated selector will ensure that function overloading
> works by adding the mangled parameter types. As an exception for
> @property setters, the compiler will convert function 'name' to selector
> 'setName:' which should make properties work with key-value coding. For
> @IBAction functions, it'll use directly the name of the function.
>
> So you should rarely have to specify the selector unless you're writing
> bindings to existing Objective-C objects. And, hopefully, creating
> bindings can be automated.

I already have a Ruby script/tool that automatically creates Objective-C bindings. But these bindings are not optimal (require some manual editing), it would also require to update the script for this syntax.

But now I've stared on a new tool based on Clang that creates Objective-C bindings and it's working A LOT better then the Ruby script. Having the tool based on a complete frontend is a HUGE improvement and makes the development processes easier.

-- 
/Jacob Carlborg