D/Objective-C: hit a dead end, start anew
Jacob Carlborg
doob at me.com
Fri Sep 17 07:06:27 PDT 2010
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
More information about the Digitalmars-d-announce
mailing list