On 2010-09-17 05:06:24 -0400, Jacob Carlborg <d...@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.for...@michelf.com
http://michelf.com/
