On 2009-09-06 07:52:27 -0400, Jacob Carlborg <d...@me.com> said:
On 9/6/09 12:51, Michel Fortin wrote:
On 2009-09-06 06:10:03 -0400, Jacob Carlborg <d...@me.com> said:
I've been thinking for a while what it would take to get D running on
the Objective-C runtime, in other words a D object will actually be an
objc object, kind of like MacRuby but for D. How difficult it would
be, how much work, what needs to change, both the runtime and the
compiler? And if it would be worth the trouble.
The reason for this is to make it easier to interface with Mac OS X
system libraries like Cocoa.
It certainly could be done, but first you'd need a way to handle the
differences between Objective-C and D methods:
- Objective-C methods are of the form "setObject:forKey:", which is
difficult to map to D.
I was thinking you sill have to create bindings and use objc_msgSend
and friends. Or something like "extern (Objc) void foo (int arg1, int
arg2);" would automatically be converted to "objc_msgSend(this,
sel_registerName("foo:arg2"), arg1, arg2);".
That doesn't scale very well. Overloading allows both "foo(int arg1,
int arg2)" and "foo(int arg1, float arg2)" to exist in the same scope,
both would become "foo:arg2:".
- Objective-C methods do not support overloading.
"void foo (int arg1, int arg2)" could be transformed to "foo:arg2" or similar.
Yeah, but what if you have foo(int a) and foo(float a)? Then you need
some kind of name mangling:
foo(int a) becomes - fooInt:(int)a
foo(float a) becomes - fooFloat:(int)a
and now the two can exist at the same time in the same class.
- Objective-C class methods (equivalent to D static member functions)
are "virtual", this is used within Cocoa
This would be a problem.
- Objective-C 2.0 allows a default method implementation in protocols
(equivalent to D interfaces).
- Templates, exceptions?
D would use the the objc exceptions and add new exception classes where
necessary. Templates would probably be disallowed.
So now the base exception class is NSException?
If all you wanted was to make D work using the Objective-C runtime (with
overloading), you could apply some special name mangling rules, but that
would make it pretty incompatible with anything really in Objective-C.
On the other side, you could change the D method syntax to disallow
overloading, use that colon-separated-multiple-part syntax, depend on
static methods being "virtual" (this pattern is used at some places in
Cocoa) and add the capability to interfaces to have default
implementations. but then it wouldn't really be D.
I do not want the colon-separated-multiple-part syntax. I don't want to
modify the compiler too much, I sill want it to be D but virtual static
methods could be an acceptable modification for example.
Hum, I think if someone wanted to have Objective-C compatibility it'd
be better to just add a different syntax for declaring Objective-C
classes than to try to fit them within D classes, much like with
Objective-C++.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
