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