Re: D/Objective-C, extern (Objective-C)
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
Re: D/Objective-C, extern (Objective-C)
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.
Re: D/Objective-C, extern (Objective-C)
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
Re: D/Objective-C, extern (Objective-C)
On 2013-06-26 11:07:45 +, Sönke Ludwig 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.for...@michelf.ca
http://michelf.ca/
Re: D/Objective-C, extern (Objective-C)
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
Re: D/Objective-C, extern (Objective-C)
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.
Re: D/Objective-C, extern (Objective-C)
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
Re: D/Objective-C, extern (Objective-C)
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
;
linkageAttributeToken: identifier | '-' | '++' | '#' | '.';
Re: D/Objective-C, extern (Objective-C)
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).
Re: D/Objective-C, extern (Objective-C)
On 26 June 2013 04:06, Walter Bright 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.
Re: D/Objective-C, extern (Objective-C)
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
Re: D/Objective-C, extern (Objective-C)
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.
Re: D/Objective-C, extern (Objective-C)
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
Re: D/Objective-C, extern (Objective-C)
On 2013-06-25 18:06:33 +, Walter Bright 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.for...@michelf.ca http://michelf.ca/
Re: D/Objective-C, extern (Objective-C)
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)
Re: D/Objective-C, extern (Objective-C)
On Monday, 24 June 2013 at 22:39:13 UTC, Steven Schveighoffer wrote: On Mon, 24 Jun 2013 18:10:19 -0400, bearophile 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
Re: D/Objective-C, extern (Objective-C)
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
Re: D/Objective-C, extern (Objective-C)
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
Re: D/Objective-C, extern (Objective-C)
Am Mon, 24 Jun 2013 22:30:56 +0200
schrieb Jacob Carlborg :
> 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.
Re: D/Objective-C, extern (Objective-C)
On Mon, 24 Jun 2013 18:10:19 -0400, bearophile 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
Re: D/Objective-C, extern (Objective-C)
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
Re: D/Objective-C, extern (Objective-C)
On 6/24/2013 1:45 PM, Steven Schveighoffer wrote: On Mon, 24 Jun 2013 16:36:50 -0400, Suliman 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.
Re: D/Objective-C, extern (Objective-C)
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
Re: D/Objective-C, extern (Objective-C)
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
Re: D/Objective-C, extern (Objective-C)
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
Re: D/Objective-C, extern (Objective-C)
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.
Re: D/Objective-C, extern (Objective-C)
On Mon, 24 Jun 2013 16:36:50 -0400, Suliman 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
Re: D/Objective-C, extern (Objective-C)
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
Re: D/Objective-C, extern (Objective-C)
Could anybody explain the practical side of this project? Where it can be helpful?
Re: D/Objective-C, extern (Objective-C)
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
Re: D/Objective-C, extern (Objective-C)
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!
Re: D/Objective-C, extern (Objective-C)
On 2013-06-24 17:53:40 +, Walter Bright 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.for...@michelf.ca http://michelf.ca/
Re: D/Objective-C, extern (Objective-C)
On Mon, 24 Jun 2013 14:25:40 -0400, Walter Bright 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
Re: D/Objective-C, extern (Objective-C)
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.)
Re: D/Objective-C, extern (Objective-C)
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 ')'
;
Re: D/Objective-C, extern (Objective-C)
On Mon, 24 Jun 2013 13:53:40 -0400, Walter Bright 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
Re: D/Objective-C, extern (Objective-C)
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.
Re: D/Objective-C, extern (Objective-C)
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.
Re: D/Objective-C, extern (Objective-C)
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.
Re: D/Objective-C, extern (Objective-C)
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.
Re: D/Objective-C, extern (Objective-C)
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
Re: D/Objective-C, extern (Objective-C)
On 2013-06-24 10:04:01 +, Jacob Carlborg 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.for...@michelf.ca http://michelf.ca/
Re: D/Objective-C, extern (Objective-C)
On 2013-06-23 20:24:41 +, Jacob Carlborg 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.for...@michelf.ca http://michelf.ca/
Re: D/Objective-C, extern (Objective-C)
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
Re: D/Objective-C, extern (Objective-C)
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
Re: D/Objective-C, extern (Objective-C)
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
Re: D/Objective-C, extern (Objective-C)
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!
Re: D/Objective-C, extern (Objective-C)
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
