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

[Jacob Carlborg]

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