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/

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

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/

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?

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/

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!

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.

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.

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/

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.