"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.1199.1332962802.4860.digitalmars-d@puremagic.com...
>
> ( [...] ( [...] ( [...] (Gah, I'm starting to Lisp, better stop now!))))
>

lol :)

On Wednesday, 28 March 2012 at 15:31:26 UTC, Bennie Copeland wrote:
> Great to hear someone with experience with it. Was there any issues with the code that had to be tweaked depending on the OS? When I was looking at C++, there was implementation defined data type sizes, endieness, implementation defined order of variables in a struct, etc. On that topic, what do I have to consider in D if I want binary compatibility in files saved on different OS's?

I cannot give you any advice as regards C++, because I have never really used it - avoiding it like the plague. My strategy is to keep things as simple as possible and use C only as the "glue". It's a bit like the Lua approach which only uses ANSI C to ensure maximum portability.

Since I have just started to put the pieces together, I have yet to test whether it works on all platforms. I haven't tested it on Windows yet and don't know where the pitfalls are (and I am sure there are some!). It is amazing, though, how easily C code can be integrated into a D program. I have to use two external frameworks/libraries written in C (one of them the utf8proc library). With a few lines of code I've got all the functionality I need without writing any wrappers.

I have not yet used Objective-C with D directly. Does anyone have experience with that?

On 2012-03-29 11:12, Chris W. wrote:

> I cannot give you any advice as regards C++, because I have never really
> used it - avoiding it like the plague. My strategy is to keep things as
> simple as possible and use C only as the "glue". It's a bit like the Lua
> approach which only uses ANSI C to ensure maximum portability.
>
> Since I have just started to put the pieces together, I have yet to test
> whether it works on all platforms. I haven't tested it on Windows yet
> and don't know where the pitfalls are (and I am sure there are some!).
> It is amazing, though, how easily C code can be integrated into a D
> program. I have to use two external frameworks/libraries written in C
> (one of them the utf8proc library). With a few lines of code I've got
> all the functionality I need without writing any wrappers.
>
> I have not yet used Objective-C with D directly. Does anyone have
> experience with that?

I have some with using Objective-C together with D. It's a lot more verbose and quite more complicated than using a C library with D.

How complicated it is depends on what one want to do with the Objective-C library. Obviously one want to create Objective-C objects and call Objective-C methods. But if it's necessary to create subclasses in D and have Objective-C create instances of those classes and call methods on the objects it gets even more complicated.

I would recommend to have a look at Michel Fortin's fork of DMD which adds support for binding to Objective-C code directly, i.e. extern(Objective-C). Note that it's not 100% complete and based on an older version of DMD.

http://michelf.com/projects/d-objc/

-- 
/Jacob Carlborg

On Thursday, 29 March 2012 at 12:10:17 UTC, Jacob Carlborg wrote:
> I have some with using Objective-C together with D. It's a lot more verbose and quite more complicated than using a C library with D.
>
> How complicated it is depends on what one want to do with the Objective-C library. Obviously one want to create Objective-C objects and call Objective-C methods. But if it's necessary to create subclasses in D and have Objective-C create instances of those classes and call methods on the objects it gets even more complicated.
>
> I would recommend to have a look at Michel Fortin's fork of DMD which adds support for binding to Objective-C code directly, i.e. extern(Objective-C). Note that it's not 100% complete and based on an older version of DMD.
>
> http://michelf.com/projects/d-objc/

Thanks for the link. Objective-C is basically C and can be implemented in C style as far as I know. Is it worth going down to the C level like so:

struct NSObject {
struct objc_class* isa;
}
struct objc_class {
    Class isa;
    Class super_class;
    const char *name;
    long version;
    long info;
    long instance_size;
    struct objc_ivar_list *ivars;
    struct objc_method_list **methodLists;
    struct objc_cache *cache;
    struct objc_protocol_list *protocols;
}

Just a random thought.

On 2012-03-29 14:44, Chris W. wrote:

> Thanks for the link. Objective-C is basically C and can be implemented
> in C style as far as I know. Is it worth going down to the C level like so:

Yes that would be possible.

> struct NSObject {
> struct objc_class* isa;
> }
> struct objc_class {
> Class isa;
> Class super_class;
> const char *name;
> long version;
> long info;
> long instance_size;
> struct objc_ivar_list *ivars;
> struct objc_method_list **methodLists;
> struct objc_cache *cache;
> struct objc_protocol_list *protocols;
> }
>
> Just a random thought.

That's the alternative approach, I've done that as well. It's very tedious and becomes verbose very fast.

Both I and Michel have created an Objective-C/D bridge that uses this approach. It lets you call Objective-C methods, create instances of Objective-C classes, create subclasses in D that inherit from Objective-C classes and so on. It did this all automatically. The problem with the bridge was the enormous template bloat. A GUI Hello World application takes around 60MB with the bridge.

http://www.dsource.org/projects/dstep
http://michelf.com/projects/d-objc-bridge/

That's why Michel started the DMD fork to directly support binding to Objective-C classes and methods.

If you just have a small amount of Objective-C code that needs to be called and basically never changes then it won't be a problem using the Objective-C runtime functions. Otherwise I wouldn't recommend it.

I've ported the SDL initialization code for Mac OS X to D, to be used in derelict. This doesn't contain any fancy templates like the bridge uses to help making the code less verbose. It's quite a lot of D code compared to the Objective-C code:

http://dsource.org/projects/derelict/browser/branches/Derelict2/DerelictSDL/derelict/sdl/macinit

This would be the original Objective-C code:

http://codespeak.net/svn/pypy/dist/pypy/rlib/rsdl/macosx-sdl-main/SDLMain.m

If you're going with this approach you could have a look at my bridge if you need help, it has some useful documentation of how it works and is implemented:

http://www.dsource.org/projects/dstep/wiki/ObjcBridge/BridgeInternals

-- 
/Jacob Carlborg

On Thursday, 29 March 2012 at 16:36:57 UTC, Jacob Carlborg wrote:
> On 2012-03-29 14:44, Chris W. wrote:
>
>> Thanks for the link. Objective-C is basically C and can be implemented
>> in C style as far as I know. Is it worth going down to the C level like so:
>
> Yes that would be possible.
>
>> struct NSObject {
>> struct objc_class* isa;
>> }
>> struct objc_class {
>> Class isa;
>> Class super_class;
>> const char *name;
>> long version;
>> long info;
>> long instance_size;
>> struct objc_ivar_list *ivars;
>> struct objc_method_list **methodLists;
>> struct objc_cache *cache;
>> struct objc_protocol_list *protocols;
>> }
>>
>> Just a random thought.
>
> That's the alternative approach, I've done that as well. It's very tedious and becomes verbose very fast.
>
> Both I and Michel have created an Objective-C/D bridge that uses this approach. It lets you call Objective-C methods, create instances of Objective-C classes, create subclasses in D that inherit from Objective-C classes and so on. It did this all automatically. The problem with the bridge was the enormous template bloat. A GUI Hello World application takes around 60MB with the bridge.
>
> http://www.dsource.org/projects/dstep
> http://michelf.com/projects/d-objc-bridge/
>
> That's why Michel started the DMD fork to directly support binding to Objective-C classes and methods.
>
> If you just have a small amount of Objective-C code that needs to be called and basically never changes then it won't be a problem using the Objective-C runtime functions. Otherwise I wouldn't recommend it.
>
> I've ported the SDL initialization code for Mac OS X to D, to be used in derelict. This doesn't contain any fancy templates like the bridge uses to help making the code less verbose. It's quite a lot of D code compared to the Objective-C code:
>
> http://dsource.org/projects/derelict/browser/branches/Derelict2/DerelictSDL/derelict/sdl/macinit
>
> This would be the original Objective-C code:
>
> http://codespeak.net/svn/pypy/dist/pypy/rlib/rsdl/macosx-sdl-main/SDLMain.m
>
> If you're going with this approach you could have a look at my bridge if you need help, it has some useful documentation of how it works and is implemented:
>
> http://www.dsource.org/projects/dstep/wiki/ObjcBridge/BridgeInternals

Thanks for your help. My primary use case is to provide a native look and feel GUI on the Mac. So, to the extent of creating the interface using Cocoa and tying it back to the core code written in D.

On Thu, 29 Mar 2012 21:03:05 +0200
"Bennie Copeland" <mugen.kanosei@gmail.com> wrote:

> Thanks for your help. My primary use case is to provide a native look and feel GUI on the Mac. So, to the extent of creating the interface using Cocoa and tying it back to the core code written in D.

Have you considered using wxD? New version on which Andrej is working at the moment will support wx-2.9.x/3.0 for which there is new Cocoa port.


Sincerely,
Gour


-- 
There is no work that affects Me; nor do I aspire for the fruits of action. One who understands this truth about Me also does not become entangled in the fruitive reactions of work.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

On 2012-03-29 21:03, Bennie Copeland wrote:

> Thanks for your help. My primary use case is to provide a native look
> and feel GUI on the Mac. So, to the extent of creating the interface
> using Cocoa and tying it back to the core code written in D.

In that case you would, hopefully, only need a new functions declared as extern (C) in the D code which the Objective-C code calls. Make the separation as clear as possible and make the interaction between the languages minimal.

-- 
/Jacob Carlborg

On 2012-03-29 21:45, Gour wrote:
> On Thu, 29 Mar 2012 21:03:05 +0200
> "Bennie Copeland"<mugen.kanosei@gmail.com>  wrote:
>
>> Thanks for your help. My primary use case is to provide a native
>> look and feel GUI on the Mac. So, to the extent of creating the
>> interface using Cocoa and tying it back to the core code written
>> in D.
>
> Have you considered using wxD? New version on which Andrej is working at
> the moment will support wx-2.9.x/3.0 for which there is new Cocoa port.

That would be another idea. It would also be possible to add some Objective-C code, or D code that calls Objective-C code, to do some platform specific functionality that wxD and wxWidget can't handle.

-- 
/Jacob Carlborg

That's all great stuff. Thanks guys. I think in this respect D could really take off, i.e. as the natively compiled, portable "core language" that can easily interface to platform specific frameworks through C and C++. This, among other things, got me interested in D in the first place. I think developers are less and less willing to re-implement their programs (or portions of it) for each platform – especially now that mobile devices add yet another array of OSes to the market. It's a question of time, money, maintenance and last but not least of trying to avoid more work (doing the same thing really).