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

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.

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

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.

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

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?

-- 
/Jacob Carlborg

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

On 2010-09-17 13:25, Michel Fortin wrote:
> On 2010-09-17 05:06:24 -0400, Jacob Carlborg <doob@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

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

On 2010-09-17 10:06:27 -0400, Jacob Carlborg <doob@me.com> said:

> Have you thought about what needs to be modified/added yet? Is it basically better support for runtime reflection?

Basically I'm adding the necessary pieces so that DMD can generate object files containing the exact same things an the Objective-C compiler would generate. I am also adding the few necessary syntactic additions to support this. The end result should be as efficient as the Objective-C compiler itself.

One thing I am *not* doing is adding the alien Objective-C syntax to D. Declaring an Objective-C class will look like this:

	extern (Objective-C)
	class NSObject {
		NSString description() @property;
		void perform(SEL selector, NSObject object) [performSelector:withObject:];
	}

and for the most part should be semantically equivalent to a regular D class. The only cases where I'm adding to the syntax are those where special things need to be expressed, such as the Objective-C selector when necessary for one of the two methods above.

Most of the work is being done in the glue code that links the frontend to the backend. I'm trying to not affect the semantics of any D construct, simply binding them to the Objective-C runtime where appropriate.

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

On 2010-09-17 16:56, Michel Fortin wrote:
> On 2010-09-17 10:06:27 -0400, Jacob Carlborg <doob@me.com> said:
>
>> Have you thought about what needs to be modified/added yet? Is it
>> basically better support for runtime reflection?
>
> Basically I'm adding the necessary pieces so that DMD can generate
> object files containing the exact same things an the Objective-C
> compiler would generate. I am also adding the few necessary syntactic
> additions to support this. The end result should be as efficient as the
> Objective-C compiler itself.
>
> One thing I am *not* doing is adding the alien Objective-C syntax to D.
> Declaring an Objective-C class will look like this:
>
> extern (Objective-C)
> class NSObject {
> NSString description() @property;
> void perform(SEL selector, NSObject object) [performSelector:withObject:];
> }
>
> and for the most part should be semantically equivalent to a regular D
> class. The only cases where I'm adding to the syntax are those where
> special things need to be expressed, such as the Objective-C selector
> when necessary for one of the two methods above.
>
> Most of the work is being done in the glue code that links the frontend
> to the backend. I'm trying to not affect the semantics of any D
> construct, simply binding them to the Objective-C runtime where
> appropriate.

Sounds good, I also once thought about adding extern (Objective-C) to the language. About the selector syntax, wouldn't it be better to have the same syntax as in Objective-C, @selector(performSelector:withObject:). I mean D already has the @annotation syntax for annotations/attributes I don't think we need yet another one. I would also be nice to use @selector(performSelector:withObject:) as an expression (or what is called) to get the selector to a method just like in Objective-C.

Have you thought anything about the blocks that Apple added in Snow Leopard, if those could be supported as well?

What about Objective-C categories?

-- 
/Jacob Carlborg

On 2010-09-17 11:50:51 -0400, Jacob Carlborg <doob@me.com> said:

> Sounds good, I also once thought about adding extern (Objective-C) to the language. About the selector syntax, wouldn't it be better to have the same syntax as in Objective-C, @selector(performSelector:withObject:). I mean D already has the @annotation syntax for annotations/attributes I don't think we need yet another one. I would also be nice to use @selector(performSelector:withObject:) as an expression (or what is called) to get the selector to a method just like in Objective-C.

I though about it, but decided against it. The @attribute syntax in D isn't meant *at this time* to accept arguments. Nor is the DMD front end ready to accept arguments for attributes. I don't want to inject my code in the parsing of attributes and their propagation through the frontend. Perhaps one day attributes will accept arguments and we could reconsider. But in the meanwhile I try to avoid touching things which are good candidates for possible future extensions to the regular D language.

Also note that member functions of an extern (Objective-C) class or interface always have implicitly a selector (made from the function's name followed by as many colons as there are arguments). The special selector syntax is only needed to specify a different selector than the original. I'm not sure if this kind of implicit thing that you can override fit very well with the notion of an attribute (certainly not the current notion which is basically a binary flag).

For the same reason, I don't think reusing Objective-C's "@selector(setObject:forKey:)" syntax for selector literals is a very good idea. I'm not exactly sure what selector literals should look like, but I'm currently leaning about simply making it a function intrinsic:

	import objc;

	SEL s = objc.selector("setObject:forKey:");


> Have you thought anything about the blocks that Apple added in Snow Leopard, if those could be supported as well?
> 
> What about Objective-C categories?

Ideally blocks would be the same as delegates, but I hadn't given them much thought yet.

I'm not sure whether I want to support creating new categories in D; categories are quite "un-D-like" and despite their usefulness they're clash-prone. But I sure want to be able to access categories from existing Objective-C frameworks. So how exactly this would work? I don't know.

In any case, I have much work to do before it's time to think about categories and blocks. The most basic problem to solve in this all new Objective-C "bridge" is the memory management. But I don't want to look at this too much until I get the basics working.


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

On 2010-09-17 19:45, Michel Fortin wrote:
> On 2010-09-17 11:50:51 -0400, Jacob Carlborg <doob@me.com> said:
>
>> Sounds good, I also once thought about adding extern (Objective-C) to
>> the language. About the selector syntax, wouldn't it be better to have
>> the same syntax as in Objective-C,
>> @selector(performSelector:withObject:). I mean D already has the
>> @annotation syntax for annotations/attributes I don't think we need
>> yet another one. I would also be nice to use
>> @selector(performSelector:withObject:) as an expression (or what is
>> called) to get the selector to a method just like in Objective-C.
>
> I though about it, but decided against it. The @attribute syntax in D
> isn't meant *at this time* to accept arguments. Nor is the DMD front end
> ready to accept arguments for attributes. I don't want to inject my code
> in the parsing of attributes and their propagation through the frontend.
> Perhaps one day attributes will accept arguments and we could
> reconsider. But in the meanwhile I try to avoid touching things which
> are good candidates for possible future extensions to the regular D
> language.
>
> Also note that member functions of an extern (Objective-C) class or
> interface always have implicitly a selector (made from the function's
> name followed by as many colons as there are arguments).

Will it use the parameter names to build the selector as well?

> The special selector syntax is only needed to specify a different selector than the
> original. I'm not sure if this kind of implicit thing that you can
> override fit very well with the notion of an attribute (certainly not
> the current notion which is basically a binary flag).

Ok, that make sense.

> For the same reason, I don't think reusing Objective-C's
> "@selector(setObject:forKey:)" syntax for selector literals is a very
> good idea. I'm not exactly sure what selector literals should look like,
> but I'm currently leaning about simply making it a function intrinsic:
>
> import objc;
>
> SEL s = objc.selector("setObject:forKey:");

I also made a selector method that takes an alias as a parameter and automcatcally builds a selector based on the name of the method and the parameter names.

>> Have you thought anything about the blocks that Apple added in Snow
>> Leopard, if those could be supported as well?
>>
>> What about Objective-C categories?
>
> Ideally blocks would be the same as delegates, but I hadn't given them
> much thought yet.

Exactly, but I assume that would make them incompatible with existing D delegates.

> I'm not sure whether I want to support creating new categories in D;
> categories are quite "un-D-like" and despite their usefulness they're
> clash-prone. But I sure want to be able to access categories from
> existing Objective-C frameworks. So how exactly this would work? I don't
> know.

Well, most of the stuff that makes Objective-C what it is, is not very D-like. D and Objective-C has different object models, D is Simula based and Objective-C is based on Smalltalk. But categories are a must, I mean a large part of the standard classes (i.e. NSObject) is split in categories. With the standard frameworks that wouldn't be such a big problem, just make regular methods of it in the class it extends, but when a non-standard framework have categories extending standard classes we start to have a problem.

> In any case, I have much work to do before it's time to think about
> categories and blocks. The most basic problem to solve in this all new
> Objective-C "bridge" is the memory management. But I don't want to look
> at this too much until I get the basics working.

What about using AutoZone, the Objective-C garbage collector? But that would require memory barriers I assume.

Please let me know when you start to think more about all this.

-- 
/Jacob Carlborg

On 2010-09-17 14:48:54 -0400, Jacob Carlborg <doob@me.com> said:

> On 2010-09-17 19:45, Michel Fortin wrote:
>> Also note that member functions of an extern (Objective-C) class or
>> interface always have implicitly a selector (made from the function's
>> name followed by as many colons as there are arguments).
> 
> Will it use the parameter names to build the selector as well?

No. This would be changing D's semantics. D, like C, does not require names for parameters in function prototypes, nor does it require names to be the same in overridden functions. And it's the same for Objective-C: parameters names are distinct from the selector and can be changed at will without changing the method's name.

This Objective-C method:

	- (id)getObject:(id)anObject forKey:(id)aKey;

becomes

	NSObject getObject(NSObject anObject, NSObject aKey) [getObject:forKey:];

In both cases, anObject and aKey can be changed without breaking compatibility. They're basically just names for local variables inside the function.


>> Ideally blocks would be the same as delegates, but I hadn't given them
>> much thought yet.
> 
> Exactly, but I assume that would make them incompatible with existing D delegates.

You misunderstood. I have no intention of changing the ABI for D delegates or anything already existing in D.

But it shouldn't be too hard to wrap delegates in blocks. You probably don't even need help from the compiler to do this (unless you want it to be implicit). Take a look at the spec for blocks:
<http://clang.llvm.org/docs/Block-ABI-Apple.txt>


>> I'm not sure whether I want to support creating new categories in D;
>> categories are quite "un-D-like" and despite their usefulness they're
>> clash-prone. But I sure want to be able to access categories from
>> existing Objective-C frameworks. So how exactly this would work? I don't
>> know.
> 
> Well, most of the stuff that makes Objective-C what it is, is not very D-like. D and Objective-C has different object models, D is Simula based and Objective-C is based on Smalltalk. But categories are a must, I mean a large part of the standard classes (i.e. NSObject) is split in categories. With the standard frameworks that wouldn't be such a big problem, just make regular methods of it in the class it extends, but when a non-standard framework have categories extending standard classes we start to have a problem.

I know the importance of categories. I believe there should be a way to declare categories from existing Objective-C frameworks and use them. What I'm unsure of is if you should be allowed to *define* your own, but I admit being able to declare them but not define them would be strange.


>> In any case, I have much work to do before it's time to think about
>> categories and blocks. The most basic problem to solve in this all new
>> Objective-C "bridge" is the memory management. But I don't want to look
>> at this too much until I get the basics working.
> 
> What about using AutoZone, the Objective-C garbage collector? But that would require memory barriers I assume.

An idea would be to substitute the GC in druntime with AutoZone and have it manage every piece of memory, but Apple's garbage collector doesn't support pointers to interior of blocks so it's impossible to use for regular D even if we were to add the memory barriers it wants. And having two collectors running at the same time sounds like trouble.


> Please let me know when you start to think more about all this.

I suggest you subscribe to my d-objc mailing list. I'll be posting about my progress there.
<http://lists.michelf.com/mailman/listinfo/d-objc>


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