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

[Michel Fortin]

On 2013-06-26 11:07:45 +0000, Sönke Ludwig <sludwig at 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 at michelf.ca
http://michelf.ca/