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

[Jacob Carlborg]

On 2010-09-17 16:06, Jacob Carlborg wrote:
> 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?

I can also add that I can both try to work on the compiler or the 
bindings scripts, doesn't matter. But it feels like I hit a dead end 
with the scripts, I don't think they will produce any better result than 
they currently are without a proper Objective-C/C frontend.

-- 
/Jacob Carlborg