On 2010-09-17 13:25, Michel Fortin wrote:
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.
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
