Use Objective-C 2.0 runtime interface

[GoogleCodeExporter]

... while retaining compatibility with the old interface.
The new interface is quite convenient and easy to use, so it shouldn't be
too hard. It should be done sooner or later, because the old interface is
already officially deprecated. It is also a prerequisite for 64-bit support.

Original issue reported on code.google.com by aut...@gmail.com on 10 Sep 2008 at 10:38

[GoogleCodeExporter]

I am interested in implementing at least a part of this in support of work I am 
doing.  Specifically, I would like to be able to use "Cocoa Bindings" with 
Haskell-
implemented subclasses of NSManagedObject and it appears to me that a necessary 
first step toward that working will be "proper" allocation and construction 
of the classes using the designated runtime functions.  I have dug around a bit 
in the code to get my bearings, and I would like to do the following:

- Refactor all "cbits" usage of structs objc_ivar, objc_ivar_list, objc_method, 
and obcj_method_list outside of newClass.m to a new set of structs named as 
hoc_ivar, etc.  Additionally, I would like to include size and alignment 
information in the hoc_ivar struct in place of the offset currently used in 
objc_ivar.
- Refactor all Haskell code's usage of IvarList to lists of a new opaque type 
Ivar, including wrapping HOC.NewClass.newClass to something that will marshall 
[Ivar] to struct hoc_ivar_list before calling the "cbits" newClass.
- Change the 'instance size' parameter from newClass() in newClass.h/m to be an 
"extra bytes" parameter (or eliminate it entirely based on the assumption that 
it should always be zero).  When dealing with the old runtime or the GNUStep 
runtime, the appropriate size would be calculated from the ivar list (plus the 
extra-bytes parameter).  If the parameter is eliminated entirely, a flag on the 
ivar structure could be added indicating whether to add the ivar as an 
old-style 
"indexed" ivar or a new-style "managed" one, thus giving the flexibility to 
still provide the old style ivars if necessary for some reason. 
- Implement a build flag for "objective C 2.0 mode"
- When in that mode, use the new objective C 2.0 runtime stuff to implement 
newClass.

If anyone is currently working on this or has any input about an appropriate 
strategy or ways the strategy outlined here should be modified, please let me 
know.

Original comment by james.c...@usma.edu on 5 Dec 2008 at 4:36

[GoogleCodeExporter]

Woo hoo, I'm cocoa-binding away in my Xcode.

The code is still a bit ugly, but as of r366 "branches/objc2" has working (for 
me at least) objective-C 2.0 class 
allocation and registration.

Original comment by james.c...@usma.edu on 8 Dec 2008 at 8:22

• Changed state: Started

[GoogleCodeExporter]

I am more or less satisfied with what I have in the objc2 branch.  I do not 
have a GNUstep machine on which to 
test my changes (especially the changes to the build system).  If someone could 
test it out, as well as review 
my modifications for any style or organization issues, I would appreciate it.

Original comment by james.c...@usma.edu on 9 Dec 2008 at 8:36

• Changed state: Fixed

[GoogleCodeExporter]

Thanks a lot! I hope I will get around to looking at this more closely next 
weekend.

Original comment by aut...@gmail.com on 9 Dec 2008 at 11:26