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