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).

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 | '-' | '++' | '#' | '.';

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

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.

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

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/

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

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.

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