D/Objective-C: hit a dead end, start anew

[Jacob Carlborg]

On 2010-09-17 13:25, Michel Fortin wrote:
> On 2010-09-17 05:06:24 -0400, Jacob Carlborg <doob at me.com> said:
>
>> On 2010-09-17 01:46, Michel Fortin wrote:
>>> <http://michelf.com/weblog/2010/dobjc-dead-end-start-anew/>
>>>
>>> The D/Objective-C bridge is a project that was aiming at making Cocoa
>>> usable from D.
>>>
>>> It's somewhat similar to QtD. The timing of this announcement isn't
>>> entirely coincidental with today's announcement about QtD: my
>>> announcement was ready, QtD's was the trigger for my Publish button.
>>> Even though the problems are probably quite different between the two
>>> projects, they both share a common need for runtime-reflection, playing
>>> with the object model from another language, static initialization from
>>> within mixins that shouldn't create circular module dependency, and
>>> probably a couple others.
>>
>> Are referring to the need for calling a static method on a class that
>> should be able to be loaded from a nib? In that case have you tried,
>> at runtime, inspecting the symbol table in the loaded binary and
>> getting the address to the necessary functions and calling them.
>
> Do you mean creating my own parallel implementation of static
> constructors that disregards module dependencies? That could have worked
> indeed, but I had more pressing problems to handle. Lazy initialization
> worked as a replacement, it just was just suboptimal.

Yes I also used lazy initialization as much as possible to solve the 
circular dependencies problem with the module constructors. But in this 
case I was referring to the following code example:

static this ()
{
	AppController.objcClass;
}

class AppControler : NSObject
{
....
}

I used the same approach as flectioned 
(http://dsource.org/projects/flectioned/) which is:

* Load the currently running binary
* Traverse the symbol table
* Collect the address of all D symbols ending with "objcClass"
* Covert all the collected addresses an convert them to function 
pointers and then call them.

Then the user of the library doesn't have to manually call the objcClass 
method.

>>> It is my feeling that for dealing with Objective-C, things will be much
>>> cleaner by working directly inside of the compiler. D templates are
>>> fabulous, and I'm quite amazed that I could do what I did, but the
>>> bridge creates just too much generated code to make the whole thing
>>> usable. So I think it's time for a new approach.
>>
>> I noted this as well, it creates an insanely amount of code. I also
>> noted that compiling as a dynamic library reduces the size about 50%.
>
> But even a size reduction of 50% doesn't make it much more attractive,
> it's still too big. That's basically why I've changed my approach.
>
>> I've actually been working on my own implementation of an
>> Objective-C/D bridge based on your blog posts and documentation. I've
>> never released or announcement anything but I have a project at
>> dsource: http://dsource.org/projects/dstep . I started this before
>> your bridge supported DMD because of no support for DMD or Tango and I
>> was not happy with the GPL license. I also added small enhancements in
>> some places.
>>
>> I also have ruby scripts (based on bridgesupprt) for automatically
>> creating bindings with results that are ok but not perfect. I was
>> thinking about create a tool using Clang and hopefully have a
>> completely automatic process when creating bindings.
>>
>> What would you say about working together on an Objective-C/D bridge?
>
> That'd be great. I'm probably not going to call it a bridge for long
> though: calling it a bridge won't make much sense once the object model
> is supported natively instead of through some abstraction.

No I guess, I was not completely sure which approach you were going to 
take and I had to call it something.

> You seem well ahead of me about generating bindings. Once I have
> something usable inside the compiler, it shouldn't be too hard to change
> the output of your scripts so they generate something compatible with it.

No, that would be the easy part :)

> Or maybe you want to hack the compiler source with me? :-) One thing
> I'll have to figure out is how to share the modified compiler source
> code. I could publish patches against various versions of DMD, or I
> could provide the modified frontend source stripped from the backend,
> but I have no license to redistribute the backend so I can't expose
> directly my Git repository. I should probably ask Walter, perhaps he'll
> agree about having a second copy of DMD being hosted on dsource for this
> project.

Hm, I don't know which approach would be the best. There's also ddmd, 
the D port of the frontend. They only distribute the frontend and 
makefiles for building the backend as a library and then they link it 
all together. I know that several other people/projects have got 
Walter's permission to distribute at least the compiler, as a binary.

Have you thought about what needs to be modified/added yet? Is it 
basically better support for runtime reflection?

-- 
/Jacob Carlborg