D on the Objective-C runtime?

[Michel Fortin]

On 2009-09-06 07:52:27 -0400, Jacob Carlborg <doob at me.com> said:

> On 9/6/09 12:51, Michel Fortin wrote:
>> On 2009-09-06 06:10:03 -0400, Jacob Carlborg <doob at 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.fortin at michelf.com
http://michelf.com/