D/Objective-C, extern (Objective-C)

[Sönke Ludwig]

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.