D on the Objective-C runtime?

[Jacob Carlborg]

On 9/6/09 14:18, Michel Fortin wrote:
> 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++.
>

Yeah, perhaps you're right, I was just thinking out loud.