www.digitalmars.com         C & C++   DMDScript  

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

reply Michel Fortin <michel.fortin michelf.com> writes:
<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/
Sep 16 2010
parent reply Jacob Carlborg <doob me.com> writes:
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
Sep 17 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
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/
Sep 17 2010
parent reply Jacob Carlborg <doob me.com> writes:
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
Sep 17 2010
next sibling parent Jacob Carlborg <doob me.com> writes:
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
Sep 17 2010
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
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/
Sep 17 2010
parent reply Jacob Carlborg <doob me.com> writes:
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
Sep 17 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
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/
Sep 17 2010
parent reply Jacob Carlborg <doob me.com> writes:
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
Sep 17 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
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/
Sep 17 2010
parent reply Jacob Carlborg <doob me.com> writes:
On 2010-09-18 02:18, Michel Fortin wrote:

 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.


Ok, now I'm not sure I understand. If you don't specify a selector for a 
declared method, how will the selector look like? In your example above, 
if you don't specify the selector how will it be something like:

getObject:: ?


 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>


Ok.


 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.


Ok.


 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.


Ok.


 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>


Done.


-- 
/Jacob Carlborg
Sep 18 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-09-18 06:10:53 -0400, Jacob Carlborg <doob me.com> said:


 Ok, now I'm not sure I understand. If you don't specify a selector for 
 a declared method, how will the selector look like? In your example 
 above, if you don't specify the selector how will it be something like:
 
 getObject:: ?


Exactly. Note that this is a valid selector name.

Though I might decide on something else later. I'm thinking about 
mangling the argument types in the selector to make it work better with 
overloading.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Sep 18 2010
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-09-18 16:36, Michel Fortin wrote:

 On 2010-09-18 06:10:53 -0400, Jacob Carlborg <doob me.com> said:


 Ok, now I'm not sure I understand. If you don't specify a selector for
 a declared method, how will the selector look like? In your example
 above, if you don't specify the selector how will it be something like:

 getObject:: ?


 Exactly. Note that this is a valid selector name.

 Though I might decide on something else later. I'm thinking about
 mangling the argument types in the selector to make it work better with
 overloading.


Yes, I know it's a valid selector name, I've seen it in a few places. 
But as I see it, in most cases where there is more than one parameter 
you will have to declare the selector explicitly.

-- 
/Jacob Carlborg
Sep 18 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-09-18 16:36, Michel Fortin wrote:

 On 2010-09-18 06:10:53 -0400, Jacob Carlborg <doob me.com> said:


 Ok, now I'm not sure I understand. If you don't specify a selector for
 a declared method, how will the selector look like? In your example
 above, if you don't specify the selector how will it be something like:

 getObject:: ?


 Exactly. Note that this is a valid selector name.

 Though I might decide on something else later. I'm thinking about
 mangling the argument types in the selector to make it work better with
 overloading.


What about two methods that take the same number of parameters and of 
the same types but have two distinct selectors in Objective-C, like 
insertSublayer:below: and insertSublayer:above: in the CALayer class in 
the QuartzCore framework. Should those be translated to 
insertSublayerBelow or insertSublayer_below_ or something like that? Or 
have you planed a syntax that will solve this some other way?

-- 
/Jacob Carlborg
Sep 20 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-09-20 04:23:38 -0400, Jacob Carlborg <doob me.com> said:


 On 2010-09-18 16:36, Michel Fortin wrote:

 Though I might decide on something else later. I'm thinking about
 mangling the argument types in the selector to make it work better with
 overloading.


 
 What about two methods that take the same number of parameters and of 
 the same types but have two distinct selectors in Objective-C, like 
 insertSublayer:below: and insertSublayer:above: in the CALayer class in 
 the QuartzCore framework. Should those be translated to 
 insertSublayerBelow or insertSublayer_below_ or something like that? Or 
 have you planed a syntax that will solve this some other way?


There is no automatic conversion from a selector to a D method name: 
you specify the method name (as usual) and you specify the selector (if 
you care about the selector, like in bindings). If you have a script 
that automatically creates bindings, then that script is the one that 
must figure out what method name to use for what selector.

Because of this, there is no need for the D method name to be related 
to the selector. When you call a method, the method name is used to 
find the method declaration; and the declaration contains the selector 
to use. Calling undeclared methods is unsupported (unlike in 
Objective-C).

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Sep 20 2010
parent Jacob Carlborg <doob me.com> writes:
On 2010-09-20 16:19, Michel Fortin wrote:

 What about two methods that take the same number of parameters and of
 the same types but have two distinct selectors in Objective-C, like
 insertSublayer:below: and insertSublayer:above: in the CALayer class
 in the QuartzCore framework. Should those be translated to
 insertSublayerBelow or insertSublayer_below_ or something like that?
 Or have you planed a syntax that will solve this some other way?


 There is no automatic conversion from a selector to a D method name: you
 specify the method name (as usual) and you specify the selector (if you
 care about the selector, like in bindings). If you have a script that
 automatically creates bindings, then that script is the one that must
 figure out what method name to use for what selector.

 Because of this, there is no need for the D method name to be related to
 the selector. When you call a method, the method name is used to find
 the method declaration; and the declaration contains the selector to
 use. Calling undeclared methods is unsupported (unlike in Objective-C).


Makes sense.

-- 
/Jacob Carlborg
Sep 22 2010