www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D/Objective-C, extern (Objective-C)

reply Jacob Carlborg <doob me.com> writes:
As some of you might know Michel Fortin created a fork of DMD a couple 
of years ago which add support for using Objective-C classes and calling 
Objective-C method. That is making D ABI compatible with Objective-C.

I have now updated it to the latest version of DMD and druntime. All 
D/Objective-C tests pass and all standard tests pass. I'm planning to 
create a DIP for this and would really like this to be folded into main 
line. For know you can read the design document created by Michel:

http://michelf.ca/projects/d-objc/syntax/

Original project page: http://michelf.ca/projects/d-objc/

My forks:
DMD: https://github.com/jacob-carlborg/dmd/tree/d-objc
druntime: https://github.com/jacob-carlborg/druntime/tree/d-objc
Phobos: standard Phobos, commit f85bd54ef5615986960fdd68ea87c8aaf5c5118d

Currently I have limited bandwidth and cannot upload a pre-compiled 
binary. To compile use the following commands:

cd dmd/src
make -f posix.mak MODEL=32 D_OBJC=1

cd druntime
make -f posix.mak DMD=../dmd/src/dmd MODEL=32 D_OBJC=1

cd phobos
make -f posix.mak DMD=../dmd/src/dmd MODEL=32

Currently D/Objc only works for 32bit. You can use Michel's example 
application, Chocolate, to try it out. It's a bit cumbersome to compile 
without Xcode but it's possible.

http://littoral.michelf.ca/code/d-objc/chocolate-dobjc-a1.zip

-- 
/Jacob Carlborg
Jun 23 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jacob Carlborg:

 http://michelf.ca/projects/d-objc/syntax/
Instead of: extern (Objective-C) Is it better to use a naming more D-idiomatic? extern (Objective_C) Regarding this syntax: void insertItem(ObjcObject object, NSInteger value) [insertItemWithObjectValue:atIndex:]; Is it possible and good to replace it with some UDA?
 I'm planning to create a DIP for this and would really like 
 this to be folded into main line.
It seems contain some different things/syntax. I don't know how much Walter&Co will appreciate it. Bye, bearophile
Jun 23 2013
next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2013-06-23, 23:02, bearophile wrote:

 Jacob Carlborg:

 http://michelf.ca/projects/d-objc/syntax/
Instead of: extern (Objective-C) Is it better to use a naming more D-idiomatic? extern (Objective_C)
There's already some precedence in extern (C++). -- Simen
Jun 23 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-23 23:02, bearophile wrote:

 Instead of:
 extern (Objective-C)

 Is it better to use a naming more D-idiomatic?

 extern (Objective_C)
As Simen said, we already have extern (C++). But I can absolutely change this if people wants to.
 Regarding this syntax:

 void insertItem(ObjcObject object, NSInteger value)
 [insertItemWithObjectValue:atIndex:];

 Is it possible and good to replace it with some UDA?
We could use an attribute. But I don't think it would be possible to use an UDA. Currently the compiler doesn't know anything about a particular UDA, all UDA's are treated the same. It it's either a built in attribute or an UDA. Doing something in between would be a lot harder.
 It seems contain some different things/syntax. I don't know how much
 Walter&Co will appreciate it.
I would say that it's very little new syntax, surprisingly. But semantically there's a lot of new stuff. But the core things are just the same as with extern (C), making D ABI compatible with another language, Objective-C. I think that this is mostly is a non-breaking change. All new keywords are prefix with two underscores, which is reserved by the compiler. A lot of stuff only apply for classes/methods declared as extern (Objective-C). * extern (Objective-C) - I wouldn't really consider this new syntax * [foo:bar:] - New syntax. Does not have to use this exact syntax but the functionality it provides is essential. * Constructors in interfaces - Not really a new syntax. Just allows an existing syntax to be used in a new place. * Foo.class - I guess this technically is new syntax. The only thing making this new syntax is the use of keyword. I we really don't want this we could rename it to __class or similar. * __classext - Not implement yet, so that's up for discussion * String literals - No new syntax. Just an implicit conversion added * BOOL __selector(NSString) - New syntax. Kind of essential to have. * Foo.protocolof - Not really a new syntax either. I don't think this is as essential as the other features. * IBOutlet and IBAction - Not implemented. This could possibly be implemented as dummy UDA's. * Blocks - Not implemented. I'm wondering if we could use the delegate keyword for this. If a delegate is marked as extern (Objective-C) it's a block. Or that might perhaps be confusing. -- /Jacob Carlborg
Jun 24 2013
next sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-06-24 10:04:01 +0000, Jacob Carlborg <doob me.com> said:

 Regarding this syntax:
 
 void insertItem(ObjcObject object, NSInteger value)
 [insertItemWithObjectValue:atIndex:];
 
 Is it possible and good to replace it with some UDA?
We could use an attribute. But I don't think it would be possible to use an UDA. Currently the compiler doesn't know anything about a particular UDA, all UDA's are treated the same. It it's either a built in attribute or an UDA. Doing something in between would be a lot harder.
Not necessarily. There's a couple of Objective-C classes that get special treatment by the compiler (identified by a pragma). One could do the same for an UDA so the compiler would know where to get that value. I'd surely have implemented it as an UDA if such a thing existed at the time. Perhaps we should use a string UDA. ;-) (joke)
 It seems contain some different things/syntax. I don't know how much
 Walter&Co will appreciate it.
I would say that it's very little new syntax, surprisingly. But semantically there's a lot of new stuff. But the core things are just the same as with extern (C), making D ABI compatible with another language, Objective-C. I think that this is mostly is a non-breaking change.
It indeed is an additive and non-breaking change.
 All new keywords are prefix with two underscores, which is reserved by 
 the compiler. A lot of stuff only apply for classes/methods declared as 
 extern (Objective-C).
 
 * extern (Objective-C) - I wouldn't really consider this new syntax
 
 * [foo:bar:] - New syntax. Does not have to use this exact syntax but 
 the functionality it provides is essential.
 
 * Constructors in interfaces - Not really a new syntax. Just allows an 
 existing syntax to be used in a new place.
And it's only allowed in extern (Objective-C) interfaces because it does not make much sense for D interfaces.
 * Foo.class - I guess this technically is new syntax. The only thing 
 making this new syntax is the use of keyword. I we really don't want 
 this we could rename it to __class or similar.
It is a new syntax. This "function" needs special semantic treatment by the compiler because it returns an object of a different class depending on the type or object you're calling it on. It also mirrors the method named "class" in Objective-C. Given these data points, it seemed appropriate to use the class keyword, which hints at the compiler magic. Hence why I tweaked the syntax to allow ".class" on Objective-C classes and objects.
 * __classext - Not implement yet, so that's up for discussion
 
 * String literals - No new syntax. Just an implicit conversion added
I'm particularly proud of those string literals. They're way cleaner than their Objective-C counterparts. :-)
 * BOOL __selector(NSString) - New syntax. Kind of essential to have.
Those too are better than their Objective-C counterpart too as they carry the argument and return type, making them less error-prone.
 * Foo.protocolof - Not really a new syntax either. I don't think this 
 is as essential as the other features.
It gives you the pointer for protocol (interface) Foo. You need that if you want to check at runtime if a class conforms to this protocol (or implements this interface in D parlance).
 *  IBOutlet and  IBAction - Not implemented. This could possibly be 
 implemented as dummy UDA's.
 
 * Blocks - Not implemented. I'm wondering if we could use the delegate 
 keyword for this. If a delegate is marked as extern (Objective-C) it's 
 a block. Or that might perhaps be confusing.
Blocks are reference-counted and don't share the two-pointer layout of a delegate. I'm not sure it'd be wise to call them delegates. But this needs some more thinking. Finally, there is a couple of features that were added to Objective-C since then that should be added to the todo list to keep feature parity. Some of those, if implemented right, could benefit the rest of D too. For instance: ARC (automatic reference counting) which is becoming a must in Objective-C. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca/
Jun 24 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/24/2013 6:27 AM, Michel Fortin wrote:
 Finally, there is a couple of features that were added to Objective-C since
then
 that should be added to the todo list to keep feature parity. Some of those, if
 implemented right, could benefit the rest of D too. For instance: ARC
(automatic
 reference counting) which is becoming a must in Objective-C.
Arc has very serious problems - I don't see how it can be done and be memory safe without adding extensive pointer annotations. The general problem is someone taking the address of a member of the reference counted object. The rc goes to zero, the objects gets deleted, and there's that dangling pointer to it.
Jun 24 2013
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 24 June 2013 at 17:53:36 UTC, Walter Bright wrote:
 Arc has very serious problems - I don't see how it can be done 
 and be memory safe without adding extensive pointer 
 annotations. The general problem is someone taking the address 
 of a member of the reference counted object. The rc goes to 
 zero, the objects gets deleted, and there's that dangling 
 pointer to it.
Just thinking out loud, but what if we were able to disable the & operator? Then if you needed its address, we could do it with some other member function that returns a special type that does the refcount. That'd be a fairly minor language change and would seal the gap that the library could then fill back in.
Jun 24 2013
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 24 Jun 2013 13:53:40 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 6/24/2013 6:27 AM, Michel Fortin wrote:
 Finally, there is a couple of features that were added to Objective-C  
 since then
 that should be added to the todo list to keep feature parity. Some of  
 those, if
 implemented right, could benefit the rest of D too. For instance: ARC  
 (automatic
 reference counting) which is becoming a must in Objective-C.
Arc has very serious problems - I don't see how it can be done and be memory safe without adding extensive pointer annotations. The general problem is someone taking the address of a member of the reference counted object. The rc goes to zero, the objects gets deleted, and there's that dangling pointer to it.
All data members in Objective-C are private. So the object can control when it gives out this data, and take appropriate actions. AFAIK, ARC does not worry about internal pointers. -Steve
Jun 24 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/24/2013 11:03 AM, Steven Schveighoffer wrote:
 All data members in Objective-C are private.  So the object can control when it
 gives out this data, and take appropriate actions.  AFAIK, ARC does not worry
 about internal pointers.
Hmm, that's a good thought. (But recall that modules allow access to private members.)
Jun 24 2013
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 24 Jun 2013 14:25:40 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 6/24/2013 11:03 AM, Steven Schveighoffer wrote:
 All data members in Objective-C are private.  So the object can control  
 when it
 gives out this data, and take appropriate actions.  AFAIK, ARC does not  
 worry
 about internal pointers.
Hmm, that's a good thought. (But recall that modules allow access to private members.)
hehe, no I mean in Objective-C, instance variables are ALWAYS private. Unless you leak that address out to the world, nobody will be getting it. Typically, you don't give out addresses to anything but Objective-C object members, which are themselves reference counted. All member variables that are 'public' are accessed via properties. If you do give out addresses to member variables, you have to be wary of this problem. -Steve
Jun 24 2013
prev sibling parent reply "Suliman" <evermind live.ru> writes:
Could anybody explain the practical side of this project? Where 
it can be helpful?
Jun 24 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 24 Jun 2013 16:36:50 -0400, Suliman <evermind live.ru> wrote:

 Could anybody explain the practical side of this project? Where it can  
 be helpful?
First, you should quote the bit of the post that you are responding to. Since you responded to my post, I will answer. Objective C is the main development language used on apple systems (iOS, MacOS X, etc). Currently, D supports MacOS X. So accessing Apple's OS framework (including GUI and other OS frameworks)from D requires either building a bridge between the two sides (basically, writing a C "glue layer" since both natively support C), or binding directly to Objective C. Given that Objective C is a superset of C, and D supports C natively, just like Objective C, the benefit is huge. Instead of calling some glue code, I can call Objective C objects directly. Unlike most languages, there would not need to be ANY significant glue code here, just a mapping of what to call when you are on an Objective C object. There should be almost no performance hit. -Steve
Jun 24 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/24/2013 1:45 PM, Steven Schveighoffer wrote:
 On Mon, 24 Jun 2013 16:36:50 -0400, Suliman <evermind live.ru> wrote:

 Could anybody explain the practical side of this project? Where it can be
 helpful?
First, you should quote the bit of the post that you are responding to. Since you responded to my post, I will answer. Objective C is the main development language used on apple systems (iOS, MacOS X, etc). Currently, D supports MacOS X. So accessing Apple's OS framework (including GUI and other OS frameworks)from D requires either building a bridge between the two sides (basically, writing a C "glue layer" since both natively support C), or binding directly to Objective C. Given that Objective C is a superset of C, and D supports C natively, just like Objective C, the benefit is huge. Instead of calling some glue code, I can call Objective C objects directly. Unlike most languages, there would not need to be ANY significant glue code here, just a mapping of what to call when you are on an Objective C object. There should be almost no performance hit.
Yup. A big win for Mac developers.
Jun 24 2013
prev sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-06-24 17:53:40 +0000, Walter Bright <newshound2 digitalmars.com> said:

 On 6/24/2013 6:27 AM, Michel Fortin wrote:
 Finally, there is a couple of features that were added to Objective-C 
 since then
 that should be added to the todo list to keep feature parity. Some of those, if
 implemented right, could benefit the rest of D too. For instance: ARC 
 (automatic
 reference counting) which is becoming a must in Objective-C.
Arc has very serious problems - I don't see how it can be done and be memory safe without adding extensive pointer annotations. The general problem is someone taking the address of a member of the reference counted object. The rc goes to zero, the objects gets deleted, and there's that dangling pointer to it.
That's not a so big problem: just disallow taking pointers to member variables inside of reference-counted memory blocks. At least in SafeD. This is a quite rare thing to do in Objective-C anyway, I'd be surprised if it bothered anyone. And I don't think it is very common in D either. Either way, if D was to implement ARC for its own memory allocator instead of the current GC (which would be great) there's noting to prevent implementing it so that reference counts could be incremented from the middle address of a memory block, it'd be quite easy in fact, and quite necessary too because of the way arrays work. Usually, the most annoying part of ARC is retain cycles, especially implicit ones created by blocks (Objective-C's delegate literals). -- Michel Fortin michel.fortin michelf.ca http://michelf.ca/
Jun 24 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/24/2013 1:18 PM, Michel Fortin wrote:
 That's not a so big problem: just disallow taking pointers to member variables
 inside of reference-counted memory blocks. At least in SafeD. This is a quite
 rare thing to do in Objective-C anyway, I'd be surprised if it bothered anyone.

 And I don't think it is very common in D either. Either way, if D was to
 implement ARC for its own memory allocator instead of the current GC (which
 would be great) there's noting to prevent implementing it so that reference
 counts could be incremented from the middle address of a memory block, it'd be
 quite easy in fact, and quite necessary too because of the way arrays work.

 Usually, the most annoying part of ARC is retain cycles, especially implicit
 ones created by blocks (Objective-C's delegate literals).
If the ref-counted blocks are allocated in the GC space, a GC run will get rid of them!
Jun 24 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/24/2013 1:18 PM, Michel Fortin wrote:
 And I don't think it is very common in D either. Either way, if D was to
 implement ARC for its own memory allocator instead of the current GC (which
 would be great) there's noting to prevent implementing it so that reference
 counts could be incremented from the middle address of a memory block, it'd be
 quite easy in fact, and quite necessary too because of the way arrays work.
From my reading about ARC, it seems to me that we should support it now rather than later because: 1. people will expect it of D 2. non-ARC is inherently unsafe 3. migrating non-ARC code to ARC is error-prone and a major nuisance 4. non-O-C programs can also benefit from ARC (after all, reliance on the GC is the perennial dealbreaker for people wanting to migrate high performance code to D)
Jun 25 2013
next sibling parent Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-06-25 18:06:33 +0000, Walter Bright <newshound2 digitalmars.com> said:

 On 6/24/2013 1:18 PM, Michel Fortin wrote:
 And I don't think it is very common in D either. Either way, if D was to
 implement ARC for its own memory allocator instead of the current GC (which
 would be great) there's noting to prevent implementing it so that reference
 counts could be incremented from the middle address of a memory block, it'd be
 quite easy in fact, and quite necessary too because of the way arrays work.
From my reading about ARC, it seems to me that we should support it now rather than later because: 1. people will expect it of D 2. non-ARC is inherently unsafe 3. migrating non-ARC code to ARC is error-prone and a major nuisance 4. non-O-C programs can also benefit from ARC (after all, reliance on the GC is the perennial dealbreaker for people wanting to migrate high performance code to D)
Exactly. Even without support for Objective-C, ARC in D is a very desirable feature. Beside that, the C++/COM WinRT API also uses ARC now, so I'd say it's becoming a must have pretty quickly. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca/
Jun 25 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-25 20:06, Walter Bright wrote:

 3. migrating non-ARC code to ARC is error-prone and a major nuisance
Xcode provides refactoring tools to migrate manual reference counting and GC code to ARC.
 4. non-O-C programs can also benefit from ARC (after all, reliance on
 the GC is the perennial dealbreaker for people wanting to migrate high
 performance code to D)
Absolutely. -- /Jacob Carlborg
Jun 25 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/25/2013 1:08 PM, Jacob Carlborg wrote:
 On 2013-06-25 20:06, Walter Bright wrote:

 3. migrating non-ARC code to ARC is error-prone and a major nuisance
Xcode provides refactoring tools to migrate manual reference counting and GC code to ARC.
Those don't work with D. Let's do it right the first time, and we won't have migration issues.
Jun 25 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-06-25 22:18, Walter Bright wrote:

 Those don't work with D.

 Let's do it right the first time, and we won't have migration issues.
Right, forgot to add: "for Objective-C". -- /Jacob Carlborg
Jun 25 2013
prev sibling parent Manu <turkeyman gmail.com> writes:
On 26 June 2013 04:06, Walter Bright <newshound2 digitalmars.com> wrote:

 On 6/24/2013 1:18 PM, Michel Fortin wrote:

 And I don't think it is very common in D either. Either way, if D was to
 implement ARC for its own memory allocator instead of the current GC
 (which
 would be great) there's noting to prevent implementing it so that
 reference
 counts could be incremented from the middle address of a memory block,
 it'd be
 quite easy in fact, and quite necessary too because of the way arrays
 work.
From my reading about ARC, it seems to me that we should support it now rather than later because: 1. people will expect it of D 2. non-ARC is inherently unsafe 3. migrating non-ARC code to ARC is error-prone and a major nuisance 4. non-O-C programs can also benefit from ARC (after all, reliance on the GC is the perennial dealbreaker for people wanting to migrate high performance code to D)
Yay! Since the conference, I'm finding myself more and more convinced that what I actually want is ARC rather than GC... although this is just a feeling, and completely untested in practise ;) But I have experience with ARC on other platforms, and the fact it results in predictable patterns makes it much easier to work with it.
Jun 25 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-24 15:27, Michel Fortin wrote:

 Not necessarily. There's a couple of Objective-C classes that get
 special treatment by the compiler (identified by a pragma). One could do
 the same for an UDA so the compiler would know where to get that value.
 I'd surely have implemented it as an UDA if such a thing existed at the
 time.
The thing is that pragmas are tied to the compiler. It knows the difference between pragma(foo) and pragma(bar). But for UDA's they are all treated the same, there's no difference between (3), ("asd") and foo from the compiler's point of view (as far as I understand). You could implement it as a new attribute (that is, not an UDA), but to implement it as an UDA would be a totally new thing.
 I'm particularly proud of those string literals. They're way cleaner
 than their Objective-C counterparts.  :-)
I agree.
 Those too are better than their Objective-C counterpart too as they
 carry the argument and return type, making them less error-prone.
Same thing here.
 Blocks are reference-counted and don't share the two-pointer layout of a
 delegate. I'm not sure it'd be wise to call them delegates. But this
 needs some more thinking.
Right, they seem kind of complicated in regards of the struct layout it's implemented as. Seems to vary quite much depending on how the block is used and how outer variables are referenced.
 Finally, there is a couple of features that were added to Objective-C
 since then that should be added to the todo list to keep feature parity.
 Some of those, if implemented right, could benefit the rest of D too.
 For instance: ARC (automatic reference counting) which is becoming a
 must in Objective-C.
Yes. There are a couple of new features that D can take advantage of without adding new language support. I'm thinking of the simplified operator overloading that was added, last year I think. We already have operator overloading and can add that to the bindings, no need for language support. If we want to add support for the new literals (numbers, arrays and associative arrays) we could do the same thing as we already done for strings. And last, modules that was added this year, D has had that for years :) -- /Jacob Carlborg
Jun 24 2013
parent reply Johannes Pfau <nospam example.com> writes:
Am Mon, 24 Jun 2013 22:30:56 +0200
schrieb Jacob Carlborg <doob me.com>:

 On 2013-06-24 15:27, Michel Fortin wrote:
 
 Not necessarily. There's a couple of Objective-C classes that get
 special treatment by the compiler (identified by a pragma). One
 could do the same for an UDA so the compiler would know where to
 get that value. I'd surely have implemented it as an UDA if such a
 thing existed at the time.
The thing is that pragmas are tied to the compiler. It knows the difference between pragma(foo) and pragma(bar). But for UDA's they are all treated the same, there's no difference between (3), ("asd") and foo from the compiler's point of view (as far as I understand). You could implement it as a new attribute (that is, not an UDA), but to implement it as an UDA would be a totally new thing.
Maybe it's new in dmd but gdc already has an UDA which is recognized by the compiler: https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/gcc/attribute.d https://github.com/D-Programming-GDC/GDC/commit/afb27a0048cbf51d40abc2810b85641d9e9af9dc The benefit of an UDA is that it does not pollute the global namespace like a normal attribute would.
Jun 24 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-06-25 08:53, Johannes Pfau wrote:

 Maybe it's new in dmd but gdc already has an UDA which is recognized by
 the compiler:
 https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/gcc/attribute.d
 https://github.com/D-Programming-GDC/GDC/commit/afb27a0048cbf51d40abc2810b85641d9e9af9dc

 The benefit of an UDA is that it does not pollute the global namespace
 like a normal attribute would.
Ok, I see. I don't know if that is implemented in DMD, not that I've heard of. But implementing this in DMD would be more work and would be yet another new feature. Note, I'm not saying I'm against it, I just want to limit how many new features are added to increase the chance of this getting into main line. -- /Jacob Carlborg
Jun 25 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/24/2013 3:04 AM, Jacob Carlborg wrote:
 On 2013-06-23 23:02, bearophile wrote:

 Instead of:
 extern (Objective-C)

 Is it better to use a naming more D-idiomatic?

 extern (Objective_C)
As Simen said, we already have extern (C++). But I can absolutely change this if people wants to.
Objective-C is just perfect.
Jun 24 2013
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Monday, 24 June 2013 at 17:51:08 UTC, Walter Bright wrote:
 On 6/24/2013 3:04 AM, Jacob Carlborg wrote:
 On 2013-06-23 23:02, bearophile wrote:

 Instead of:
 extern (Objective-C)

 Is it better to use a naming more D-idiomatic?

 extern (Objective_C)
As Simen said, we already have extern (C++). But I can absolutely change this if people wants to.
Objective-C is just perfect.
linkageAttribute: 'extern' '(' Identifier ')' | 'extern' '(' Identifier '++' ')' | 'extern' '(' Identifier '-' Identifier ')' ;
Jun 24 2013
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 24.06.2013 20:10, schrieb Brian Schott:
 On Monday, 24 June 2013 at 17:51:08 UTC, Walter Bright wrote:
 On 6/24/2013 3:04 AM, Jacob Carlborg wrote:
 On 2013-06-23 23:02, bearophile wrote:

 Instead of:
 extern (Objective-C)

 Is it better to use a naming more D-idiomatic?

 extern (Objective_C)
As Simen said, we already have extern (C++). But I can absolutely change this if people wants to.
Objective-C is just perfect.
linkageAttribute: 'extern' '(' Identifier ')' | 'extern' '(' Identifier '++' ')' | 'extern' '(' Identifier '-' Identifier ')' ;
Maybe it makes sense to generalize it instead: linkageAttribute: 'extern' '(' linkageAttributeIdentifier ')'; linkageAttributeIdentifier: linkageAttributeToken | linkageAttributeIdentifier linkageAttributeToken ;
Jun 26 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/23/2013 1:24 PM, Jacob Carlborg wrote:
 As some of you might know Michel Fortin created a fork of DMD a couple of years
 ago which add support for using Objective-C classes and calling Objective-C
 method. That is making D ABI compatible with Objective-C.

 I have now updated it to the latest version of DMD and druntime. All
 D/Objective-C tests pass and all standard tests pass. I'm planning to create a
 DIP for this and would really like this to be folded into main line. For know
 you can read the design document created by Michel:
Thank you for reviving this. Please carry on!
Jun 23 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-23 23:12, Walter Bright wrote:

 Thank you for reviving this. Please carry on!
Is there a chance we can get this into main line? -- /Jacob Carlborg
Jun 24 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/24/2013 3:04 AM, Jacob Carlborg wrote:
 On 2013-06-23 23:12, Walter Bright wrote:

 Thank you for reviving this. Please carry on!
Is there a chance we can get this into main line?
Yes, but since I don't know much about O-C programming, the feature should be labeled "experimental" until we're sure it's the right design.
Jun 24 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-24 19:36, Walter Bright wrote:

 Yes, but since I don't know much about O-C programming, the feature
 should be labeled "experimental" until we're sure it's the right design.
Absolutely. But there's not that much to design. It's the same with extern (C) nothing to design there, just get the ABI correct. Compared to extern (C) there are a few additional things that need to be designed. I suggest you try and read the design document by Michel, then comment and ask as much questions as possible. -- /Jacob Carlborg
Jun 24 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/24/2013 1:37 PM, Jacob Carlborg wrote:
 On 2013-06-24 19:36, Walter Bright wrote:

 Yes, but since I don't know much about O-C programming, the feature
 should be labeled "experimental" until we're sure it's the right design.
Absolutely. But there's not that much to design. It's the same with extern (C) nothing to design there, just get the ABI correct. Compared to extern (C) there are a few additional things that need to be designed.
The difference is I know C intimately.
 I suggest you try and read the design document by Michel, then comment and ask
 as much questions as possible.
I did read it.
Jun 24 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-06-24 22:49, Walter Bright wrote:

 The difference is I know C intimately.
Fair enough. Please ask any questions and we will try and answer.
 I did read it.
Great. -- /Jacob Carlborg
Jun 24 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 Yes, but since I don't know much about O-C programming, the 
 feature should be labeled "experimental" until we're sure it's 
 the right design.
This change opens a new target of D development (well, it was already open for the people willing to use a not standard dmd compiler), but it also introduce some extra complexity in the language, that every D programmer will have to pay forever, even all the ones that will not use those features. So such changes need to be introduced with care and after extensive discussions in the main newsgroup. Probably each one new thing introduced needs a separate discussion. Bye, bearophile
Jun 24 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-24 23:26, bearophile wrote:

 This change opens a new target of D development (well, it was already
 open for the people willing to use a not standard dmd compiler), but it
 also introduce some extra complexity in the language, that every D
 programmer will have to pay forever, even all the ones that will not use
 those features. So such changes need to be introduced with care and
 after extensive discussions in the main newsgroup. Probably each one new
 thing introduced needs a separate discussion.
I don't think it adds much complexity. If you don't use extern (Objective-C) you don't need to learn it. -- /Jacob Carlborg
Jun 24 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jacob Carlborg:

 I don't think it adds much complexity. If you don't use extern 
 (Objective-C) you don't need to learn it.
D books must be bigger, D programmers must read those parts of the books, the error messages become more complex (because you can hit by mistake the unwanted syntax, or because the compiler recovering of errors must consider more possibilities), the compiler gets a little larger. Thinking that some new syntax has no costs is very wrong. Bye, bearophile
Jun 24 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 24 Jun 2013 18:10:19 -0400, bearophile <bearophileHUGS lycos.com>  
wrote:

 Jacob Carlborg:

 I don't think it adds much complexity. If you don't use extern  
 (Objective-C) you don't need to learn it.
D books must be bigger, D programmers must read those parts of the books, the error messages become more complex (because you can hit by mistake the unwanted syntax, or because the compiler recovering of errors must consider more possibilities), the compiler gets a little larger. Thinking that some new syntax has no costs is very wrong.
I think this is largely false. In order for the new syntax to be valid, you must use extern(Objective-C). That would be quite an accident. Consider that I have never dealt with the COM compatibility (or frankly, even the extern(C++) compatibility) part of D whatsoever. Because I've never implemented IUnknown, or used extern(C++). These features that are enabled by specific syntax are not extra complexity for D. Note that TDPL makes no mention of IUnknown or COM compatibility, yet I have never seen a post on D.learn asking questions about this feature set unless they were actually looking to write COM code. In other words, no accidental enabling (I have seen questions as to why interfaces are not Objects, and I grudgingly have to point to the incorrect belief that COM objects cannot be discerned from normal D objects at compile time). On the other hand, something like shared and const are pervasive, because they are core language features, AND because they are used throughout libraries. I think it is important to consider the applicability to normal code when introducing such binding features. The way this is to be introduced is the correct level of access -- only enabled with a specific directive. -Steve
Jun 24 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-06-25 00:39, Steven Schveighoffer wrote:

 I think this is largely false.  In order for the new syntax to be valid,
 you must use extern(Objective-C).  That would be quite an accident.

 Consider that I have never dealt with the COM compatibility (or frankly,
 even the extern(C++) compatibility) part of D whatsoever.  Because I've
 never implemented IUnknown, or used extern(C++).
I agree, I never used those either.
 These features that are enabled by specific syntax are not extra
 complexity for D.

 Note that TDPL makes no mention of IUnknown or COM compatibility, yet I
 have never seen a post on D.learn asking questions about this feature
 set unless they were actually looking to write COM code.  In other
 words, no accidental enabling (I have seen questions as to why
 interfaces are not Objects, and I grudgingly have to point to the
 incorrect belief that COM objects cannot be discerned from normal D
 objects at compile time).

 On the other hand, something like shared and const are pervasive,
 because they are core language features, AND because they are used
 throughout libraries.

 I think it is important to consider the applicability to normal code
 when introducing such binding features.  The way this is to be
 introduced is the correct level of access -- only enabled with a
 specific directive.
Well put, you said it better than I ever could. -- /Jacob Carlborg
Jun 25 2013
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 24 June 2013 at 22:39:13 UTC, Steven Schveighoffer 
wrote:
 On Mon, 24 Jun 2013 18:10:19 -0400, bearophile 
 <bearophileHUGS lycos.com> wrote:

 Jacob Carlborg:

 I don't think it adds much complexity. If you don't use 
 extern (Objective-C) you don't need to learn it.
D books must be bigger, D programmers must read those parts of the books, the error messages become more complex (because you can hit by mistake the unwanted syntax, or because the compiler recovering of errors must consider more possibilities), the compiler gets a little larger. Thinking that some new syntax has no costs is very wrong.
I think this is largely false. In order for the new syntax to be valid, you must use extern(Objective-C). That would be quite an accident. Consider that I have never dealt with the COM compatibility (or frankly, even the extern(C++) compatibility) part of D whatsoever. Because I've never implemented IUnknown, or used extern(C++). These features that are enabled by specific syntax are not extra complexity for D. Note that TDPL makes no mention of IUnknown or COM compatibility, yet I have never seen a post on D.learn asking questions about this feature set unless they were actually looking to write COM code. In other words, no accidental enabling (I have seen questions as to why interfaces are not Objects, and I grudgingly have to point to the incorrect belief that COM objects cannot be discerned from normal D objects at compile time).
This will surely change if we ever want to target WinRT with D, as it is COM based and might be the future Windows default API in the long term. I am quite curious to see the presentations of this week BUILD 2012, to see what changes Microsoft might be briging to WinRT. -- Paulo
Jun 25 2013
prev sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 24.06.2013 23:26, schrieb bearophile:
 Walter Bright:
 
 Yes, but since I don't know much about O-C programming, the feature
 should be labeled "experimental" until we're sure it's the right design.
This change opens a new target of D development (well, it was already open for the people willing to use a not standard dmd compiler), but it also introduce some extra complexity in the language, that every D programmer will have to pay forever, even all the ones that will not use those features. So such changes need to be introduced with care and after extensive discussions in the main newsgroup. Probably each one new thing introduced needs a separate discussion. Bye, bearophile
I agree. Even though it may not be mentioned in books and many people may never see the changes, it still *does* make the language more complex. One consequence is that language processing tools (compilers, syntax highlighters etc.) get updated/written with this in mind. This is why I would also suggest to try and make another pass over the changes, trying to move every bit from language to library that is possible - without compromising the result too much, of course (e.g. due to template bloat like in the older D->ObjC bridge). Maybe it's possible to put some things into __traits or other more general facilities to avoid changing the language grammar. On the other hand I actually very much hate to suggest this, as it probably causes a lot of additional work. But really, we shouldn't take *any* language additions lightly, even relatively isolated ones. Like always, new syntax must be able to "pull its own weight" (IMO, of course).
Jun 26 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-26 10:54, Sönke Ludwig wrote:

 I agree. Even though it may not be mentioned in books and many people
 may never see the changes, it still *does* make the language more
 complex. One consequence is that language processing tools (compilers,
 syntax highlighters etc.) get updated/written with this in mind.
I don't think there will require much change for tools (non-compilers). I see three "big" changes, non of them are at the lexical level: extern (Objective-C) [foo:bar:] foo.class Any tool that just deals with syntax highlighting (on a lexical level) should be able to handle these changes. Sure, you might want to add a special case for "foo.class" to not highlight "class" in this case.
 This is why I would also suggest to try and make another pass over the
 changes, trying to move every bit from language to library that is
 possible - without compromising the result too much, of course (e.g. due
 to template bloat like in the older D->ObjC bridge). Maybe it's possible
 to put some things into __traits or other more general facilities to
 avoid changing the language grammar.
I don't see what could be but in __traits that could help. Do you have any suggestions?
 On the other hand I actually very much hate to suggest this, as it
 probably causes a lot of additional work. But really, we shouldn't take
 *any* language additions lightly, even relatively isolated ones. Like
 always, new syntax must be able to "pull its own weight" (IMO, of course).
I would say that for anyone remotely interested in Mac OS X or iOS development it pull its own weight several times over. In my opinion I think it's so obvious it pulls its own weight I shouldn't need to justify the changes. -- /Jacob Carlborg
Jun 26 2013
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 26.06.2013 12:09, schrieb Jacob Carlborg:
 On 2013-06-26 10:54, Sönke Ludwig wrote:
 
 I agree. Even though it may not be mentioned in books and many people
 may never see the changes, it still *does* make the language more
 complex. One consequence is that language processing tools (compilers,
 syntax highlighters etc.) get updated/written with this in mind.
I don't think there will require much change for tools (non-compilers). I see three "big" changes, non of them are at the lexical level:
I agree, it will only influence tools that include a parser. Few syntax highlighters parse the code (although *some* do), so this was probably not the best example.
 This is why I would also suggest to try and make another pass over the
 changes, trying to move every bit from language to library that is
 possible - without compromising the result too much, of course (e.g. due
 to template bloat like in the older D->ObjC bridge). Maybe it's possible
 to put some things into __traits or other more general facilities to
 avoid changing the language grammar.
I don't see what could be but in __traits that could help. Do you have any suggestions?
Naively I first thought that .class and .protocolof were candidates for __traits, but actually it looks like they might simply be implemented using a templated static property: class ObjcObject { static property ProtocolType!T protocolof(this T)() { return ProtocolType!T.staticInstance; } } That's of course assuming that the static instance is somehow accessible from normal D code. Sorry if this doesn't really make sense, I don't know anything of the implementation details. The __selector type class might be replaceable by a library type Selector!(R, ARGS). It would also be great to have general support for implicit constructors and make string->NSString and delegate->ObjcBlock available in the library instead of dedicated compiler special case. Not sure about constructors in interfaces, they seem a bit odd, but using "init" instead and letting "new" call that is also odd... You already mentioned IBAction and IBOutlet, those can obviously be UDAs, as well as optional and other similar keywords. Maybe it's possible like this to reduce the syntax additions to extern(Objective-C) and possibly constructors in interfaces.
 
 On the other hand I actually very much hate to suggest this, as it
 probably causes a lot of additional work. But really, we shouldn't take
 *any* language additions lightly, even relatively isolated ones. Like
 always, new syntax must be able to "pull its own weight" (IMO, of
 course).
I would say that for anyone remotely interested in Mac OS X or iOS development it pull its own weight several times over. In my opinion I think it's so obvious it pulls its own weight I shouldn't need to justify the changes.
I don't mean the additions as a whole of course, but each single language change vs. a library based solution of the same feature ;) In general this is a great addition from a functional view! I was very much looking forward for it to get back to life.
Jun 26 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-06-26 13:07, Sönke Ludwig wrote:

 I agree, it will only influence tools that include a parser. Few syntax
 highlighters parse the code (although *some* do), so this was probably
 not the best example.
Absolutely, some even do semantic analyze. Example, the syntax highlighter in Eclipse for Java highlights instance variables differently from identifiers. Don't know if there's any syntax highlighters for D that do this.
 Naively I first thought that .class and .protocolof were candidates for
 __traits, but actually it looks like they might simply be implemented
 using a templated static property:

 class ObjcObject {
    static  property ProtocolType!T protocolof(this T)() {
      return ProtocolType!T.staticInstance;
    }
 }
So what would ProtocolType do? I think I need to look at the implementation of .class and .protocolof. In Objective-C there are runtime functions to do the same, I don't know if those would work for D as well.
 That's of course assuming that the static instance is somehow accessible
 from normal D code. Sorry if this doesn't really make sense, I don't
 know anything of the implementation details.

 The __selector type class might be replaceable by a library type
 Selector!(R, ARGS).
Hmm, that might be possible. We would need a trait to get the selector for a method, which we should have anyway. But this uses templates again. We don't want to move everything to library code then we would have the same problem as with the bridge.
 It would also be great to have general support for
 implicit constructors and make string->NSString and delegate->ObjcBlock
 available in the library instead of dedicated compiler special case.
Since strings and delegates are already implemented in the language, would it be possible to add implicit conversions for these types in the library?
 Not sure about constructors in interfaces, they seem a bit odd, but
 using "init" instead and letting "new" call that is also odd...
Using "alloc.init" would be more Objective-C like and using "new" would be more D like.
 You already mentioned  IBAction and  IBOutlet, those can obviously be
 UDAs, as well as  optional and other similar keywords.
The compiler will need to know about optional. I don't think that the compiler will need to know about IBAction and IBOutlet, but if it does, there are a couple of advantages we could implement. IBOutlet only make sense on instance variables. IBAction only make sense on instance method with the following signature: void foo (id sender) { } Possibly any Objective-C type could be used as the argument type.
 Maybe it's possible like this to reduce the syntax additions to
 extern(Objective-C) and possibly constructors in interfaces.
I'm open to suggestions.
 I don't mean the additions as a whole of course, but each single
 language change vs. a library based solution of the same feature ;) In
 general this is a great addition from a functional view! I was very much
 looking forward for it to get back to life.
Great. It's just a question of what is possible to implement in library code. -- /Jacob Carlborg
Jun 26 2013
prev sibling parent Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-06-26 11:07:45 +0000, Sönke Ludwig <sludwig outerproduct.org> said:

 Naively I first thought that .class and .protocolof were candidates for
 __traits, but actually it looks like they might simply be implemented
 using a templated static property:
 
 class ObjcObject {
   static  property ProtocolType!T protocolof(this T)() {
     return ProtocolType!T.staticInstance;
   }
 }
 
 That's of course assuming that the static instance is somehow accessible
 from normal D code.
I don't think you get what protocolof is, or if so I can't understand what you're trying to suggest with the code above. It's a way to obtain the pointer identifying a protocol. You don't "call" protocolof on a class, but on the interface. Like this: extern (Objective-C) interface MyInterface {} NSObject object; if (object.conformsToProtocol(MyInterface.protocolof)) { … } protocolof is a pointer generated by the compiler that represents the Objective-C protocol for that interface. It's pretty much alike other compiler generated properties such as mangleof and nameof. There's nothing unusual about protocolof. And that conformsToProtocol function above is a completely normal function by the way. As for .class, it's pretty much alike to .classinfo for D objects. The difference is that it returns an instance of a different type depending on the class (Objective-C has a metaclass hierarchy), so it needs to be handled by the compiler. I used .class to mirror the name in Objective-C code. Since this has to be compiler generated and it's type is magic to be typeof(this).Class, I see no harm in using a keyword for it. I could have called it .classinfo, but that'd be rather misleading if you asked me (it's not a ClassInfo object, nor does it behave like ClassInfo).
 The __selector type class might be replaceable by a library type
 Selector!(R, ARGS).
It could. But it needs compiler support for if you want to extract them from functions in a type-safe manner. If the compiler has to understand the type, better make it a language extension.
 It would also be great to have general support for
 implicit constructors and make string->NSString and delegate->ObjcBlock
 available in the library instead of dedicated compiler special case.
String literals are implicitly convertible to NSString with absolutely no overhead.
 Not sure about constructors in interfaces, they seem a bit odd, but
 using "init" instead and letting "new" call that is also odd...
Well, there's supported in Objective-C (as init methods), so we have to support them.
 You already mentioned  IBAction and  IBOutlet, those can obviously be
 UDAs, as well as  optional and other similar keywords.
Indeed.
 Maybe it's possible like this to reduce the syntax additions to
 extern(Objective-C) and possibly constructors in interfaces.
Maybe. But not at the cost of memory safety. The idea is that something written in safe D should be memory-safe, it should be provable by the compiler. And this should apply to Objective-C code written in D too. Without this requirement we could make it less magic, and allow, for instance, NSObject.alloc().init(). But that's not safe, which is why constructors were implemented. But we can't do this at the cost of disallowing existing idioms do in Objective-C. For instance, I could get a pointer to a class object, and create a new object for it. If you define this: extern (Objective-C): interface MyProtocol { this(string); } class MyObject : NSObject, MyProtocol { this(string) {} } you can then write this: MyProtocol.Class c = MyObject.class; NSObject o = new c("baca"); And the compiler then knows that the class pointer can allocate objects that can be constructed with a string parameter. This is something that can and is done in Objective-C (hence why you'll find constructors on interfaces). The idea is to add provable memory safety on top of it. (Note that the above example is not implemented yet, nor documented.) -- Michel Fortin michel.fortin michelf.ca http://michelf.ca/
Jun 26 2013
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-06-23 20:24:41 +0000, Jacob Carlborg <doob me.com> said:

 As some of you might know Michel Fortin created a fork of DMD a couple 
 of years ago which add support for using Objective-C classes and 
 calling Objective-C method. That is making D ABI compatible with 
 Objective-C.
 
 I have now updated it to the latest version of DMD and druntime. All 
 D/Objective-C tests pass and all standard tests pass.
I know it was significant work to make it both play nice with the most recent OS X linker and port it to the newest DMD code base. Great achievement. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca/
Jun 24 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-06-24 14:49, Michel Fortin wrote:

 I know it was significant work to make it both play nice with the most
 recent OS X linker and port it to the newest DMD code base. Great
 achievement.
Thank you for all the help I've got and for you starting with this whole project. -- /Jacob Carlborg
Jun 24 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-23 22:24, Jacob Carlborg wrote:
 As some of you might know Michel Fortin created a fork of DMD a couple
 of years ago which add support for using Objective-C classes and calling
 Objective-C method. That is making D ABI compatible with Objective-C.

 I have now updated it to the latest version of DMD and druntime. All
 D/Objective-C tests pass and all standard tests pass. I'm planning to
 create a DIP for this and would really like this to be folded into main
 line. For know you can read the design document created by Michel:
I have created a proper DIP for this now. The DIP is basically Michel Fortin's original designed document properly formatted and put next to the other DIP's. DIP link: http://wiki.dlang.org/DIP43 Thread for the DIP: http://forum.dlang.org/thread/kqmlm7$1kfi$1 digitalmars.com#post-kqmlm7:241kfi:241:40digitalmars.com -- /Jacob Carlborg
Jun 29 2013
parent reply "Christian Schneider" <schneider gerzonic.net> writes:
I almost got Chocolate running on a 10.9.4 machine with all the
latest developer tools (including Xcode 6), all built from source
and 64 bit with the latest git checkouts (including phobos). Of
course it is not within Xcode but using dub, so the biggest thing
yet to do is to bundle an OSX app with dub, so far for the word
almost before ;)

This looks very promising, thank you Jacob for all the hard work!
I soon want to start to write a tutorial including a step by step
guide.
Sep 24 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-09-24 14:56, Christian Schneider wrote:
 I almost got Chocolate running on a 10.9.4 machine with all the
 latest developer tools (including Xcode 6), all built from source
 and 64 bit with the latest git checkouts (including phobos). Of
 course it is not within Xcode but using dub, so the biggest thing
 yet to do is to bundle an OSX app with dub, so far for the word
 almost before ;)

 This looks very promising, thank you Jacob for all the hard work!
 I soon want to start to write a tutorial including a step by step
 guide.
Cool, it's great to see that it's useful to someone. -- /Jacob Carlborg
Sep 24 2014