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

Michel Fortin michel.fortin at michelf.com
Fri Sep 17 04:25:44 PDT 2010


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.

>> 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.

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.

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.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/



More information about the Digitalmars-d-announce mailing list