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