www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D/Objective-C Preliminary Design

reply Michel Fortin <michel.fortin michelf.com> writes:
I posted on my blog a preliminary document outlining what I intent to 
implement in DMD to support the Objective-C object model.

<http://michelf.com/weblog/2010/dobjc-preliminary-design/>

Comments?


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Nov 03 2010
next sibling parent reply Marianne Gagnon <auria.mg gmail.com> writes:
I found a confusing part :

Here is an abbreviated declaration for NSString:
extern (Objective-C) class NSComboBox ...
This declaration [...] will let know to the compiler that the NSColor class
exists

=P
Otherwise seems nice but I'll let people that know DMD answer

--Auria

 I posted on my blog a preliminary document outlining what I intent to 
 implement in DMD to support the Objective-C object model.
 
 <http://michelf.com/weblog/2010/dobjc-preliminary-design/>
 
 Comments?
 
 
 -- 
 Michel Fortin
 michel.fortin michelf.com
 http://michelf.com/
 
Nov 03 2010
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-11-03 13:44:27 -0400, Marianne Gagnon <auria.mg gmail.com> said:

 I found a confusing part :
 
 Here is an abbreviated declaration for NSString:
 extern (Objective-C) class NSComboBox ...
 This declaration [...] will let know to the compiler that the NSColor 
 class exists
Oops, I changed my example but forgot to update the paragraph just above it. Fixed. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Nov 03 2010
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Michel Fortin wrote:
 I posted on my blog a preliminary document outlining what I intent to 
 implement in DMD to support the Objective-C object model.
 
 <http://michelf.com/weblog/2010/dobjc-preliminary-design/>
 
 Comments?
Thanks for doing this! "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?
Nov 03 2010
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-11-03 13:55:35 -0400, Walter Bright <newshound2 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.fortin michelf.com http://michelf.com/
Nov 03 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Michel Fortin wrote:
 On 2010-11-03 13:55:35 -0400, Walter Bright <newshound2 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.
 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.
Nov 03 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-11-03 18:40:36 -0400, Walter Bright <newshound2 digitalmars.com> said:

 Michel Fortin wrote:
 On 2010-11-03 13:55:35 -0400, Walter Bright <newshound2 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 michelf.com http://michelf.com/
Nov 03 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Nov 03 2010
next sibling parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
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
Nov 04 2010
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
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/
Nov 04 2010
prev sibling parent Robert Clipsham <robert octarineparrot.com> writes:
On 04/11/10 00:51, Walter Bright wrote:
 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.
It's an odd little language, took me forever to pick up even the basics, following might help clarify somewhat (although it may be incorrect, I'm sure someone will correct me if it is - I am but an amateur when it comes to ObjC). ObjC has (optional) named parameters, when it does they become part of the method name, eg: [someObj foobar]; [someObj foobar withString: "bar"]; is effectively equivalent to (in pseudo-D): someObj.foobar(); // Where pseudo-D has named parameters, and uses the same method name // as the Obj-C code someObj.foobar:withString:(withString="bar");
 I agree with all your goals.

 One possibility: simply adopt O-C syntax.
I personally would be against this, I'm sure there are a lot of people who wouldn't be though. D has a really nice, simple syntax - the only syntactic errors are purely my finger missing the ; key etc... I still struggle with Obj-C syntax, heck, you can get Obj-C syntax wrong and it'll still compile with no warnings, then you're left wondering why your app is segfaulting. -- Robert http://octarineparrot.com/
Nov 04 2010
prev sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
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
Nov 04 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
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/
Nov 04 2010
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Nov 04 2010
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Michel Fortin Wrote:

 On 2010-11-03 13:55:35 -0400, Walter Bright <newshound2 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.
Nov 03 2010
parent Paolo Invernizzi <arathorn nospam.net> writes:
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
Nov 04 2010
prev sibling parent BCS <anon anon.com> writes:
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.
Nov 03 2010
prev sibling parent lurk <lurk lurk.rk> writes:
Nick Sabalausky Wrote:

 "%u" <user web.news> wrote in message news:iap1l4$17hk$1 digitalmars.com...
I found a slideshow called 'The Expressiveness of Go' recently. The 
conclusions are:

 * Go is not a small language but it is an expressive and comprehensible 
 one.

 * Expressiveness comes from orthogonal composition of constructs.

 * Comprehensibility comes from simple constructs that interact in easily 
 understood ways.

 * Build a language from simple orthogonal constructs and you have a 
 language that will be easy and productive to use.

 * The surprises you discover will be pleasant ones.
I know how much the Unix creators (ie, Go creators) *love* taking orthogonality to extremes. I find that leads to puritanical languages that actively avoid pragmatism (ie, some of the worst kinds of languages). Orthogonality is good for *machines*,
What does that mean? Makes the microchips smile in lecherous ways? Seriously kid, have you ever heard of pure von Neumann or RAM architectures. Those are horribly impractical because as we know, some hardware components are suboptimal (ALUs faster than memory modules). Orthogonality is good for humans. Less rules to remember. The search space is smaller. The mental abilities can only manage a finite amount of entities concurrently. You either make it all simpler in the first place or shove all that complexity in your ass with abstractions.
 but not quite as much for humans (in 
 moderation, yes, in large doses, no).
Seriously? How do I know?
 Even programmers aren't as 
 orthogonally-minded as we often think we are.
Maybe you aren't! After all, you're using D 2.0 and all! Selection bias, you know.
 It's a bad idea for them, and 
 it's just gonna lead to another Java/Smalltalk/Haskel/etc
Oh dear, orthogonality would lead to yet another most popular language in the world. First there was Java (damn, terribly popular) and now Python (even more orthogonal and quicky getting past Java in popularity -- for example Python has more orthogonal tuples than D or Java, it's getting a lot of attention, and even small kids are using it! oh dear oh dear! So much non-pragmatism! And they're forcing it down kids' throats! It's a rape!)
, and we've already 
 got a million of those, we certainly don't need yet another.
You've got the most promising unorthogonal language in front of you. I think you've succeeded nicely. No other language has as many keywords, as many special cases and as many compiler bugs. Only the ones with most faith will worship it!
 I find it 
 really odd that no matter how many times people keep trying that 
 purity-not-pragmatic approach to language design and end up with junk, 
 others still keep trying to make "better" languages by using the same damn 
 ideology that led to the problems in the first place.
Would you build me a fucking pure pragmatic language. I need 110% pure pragmatism now. Even the language's name should reflect this fact - let's call it The Pure Pragma Language 2.0. Or between me and U, we can secretly call it the 'Hype oriented number 1 marketing bullshit language (fixing bugs was never this easy: never write new code, just believe and shout the truth, the louder the better)'. I'm so gonna rule the world with my pragmatic pragmatism. I want zero non-pragmatic features, only pure practical real world pragmatic serious power! Now what are these features? You don't know - only your god knows! Conclusion: it's so much more pragmatic to leave a half-baked implementation of (value) tuples in the compiler and confuse users for the eternity. It's so much more practical to add tuples into the library and introduce some braindead stupid new unorthogonal syntax for these to make them as repelling as possible. After all, all other modern languages are making them easier to use and use the same ugly (vomit vomit) orthogonal syntax. We must fight back!
Nov 03 2010
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Michel Fortin Wrote:

 I posted on my blog a preliminary document outlining what I intent to 
 implement in DMD to support the Objective-C object model.
 
 <http://michelf.com/weblog/2010/dobjc-preliminary-design/>
 
 Comments?
It looks like a few things are already implemented. I'd recommend submitting a basic O-C patch and seek Walter's feedback. 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.
 
 
 -- 
 Michel Fortin
 michel.fortin michelf.com
 http://michelf.com/
 
Nov 03 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
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/
Nov 04 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Michel Fortin wrote:
 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.
 
You have my permission to do it as long as you don't change the license. I think you are quite right to release this as an experimental fork until we're sure it's the right approach, rather than jack users around with fundamental changes.
Nov 06 2010
prev sibling parent reply Kagamin <spam here.lot> writes:
Michel Fortin Wrote:

 I posted on my blog a preliminary document outlining what I intent to 
 implement in DMD to support the Objective-C object model.
 
 <http://michelf.com/weblog/2010/dobjc-preliminary-design/>
 
 Comments?
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.
Nov 04 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
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/
Nov 04 2010
parent Jacob Carlborg <doob me.com> writes:
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
Nov 04 2010