Hi Gregory,
Objective-C 2.0 ===== Odds are the existing developers will still write for versions of Mac OS 10.4 and below in order to have the widest possible range of customers, but eventually Objective-C 2.0 *will* become the standard. As more and more people upgrade this will become the case sooner rather than later. The core libraries of GNUstep should remain ObjC "1.0" compatible for the forseeable future, but I believe we need to start talking to the people in the GCC project to determine how we can help with the implementation of a gnu runtime that works with the new version of the language.
Looking at the interfaces to the Apple runtime, it seems like they have made some very significant changes. Classes are now an opaque type; if you compile with Objective-C 2.0, the only visible field in the Class structure is the isa pointer. A few of the runtime functions are interesting; the method_setImplementation() and method_exchangeImplementations() functions could potentially be used to allow safe IMP caching (provide some mechanism for indicating a cache location so they can be invalidated if the IMP changes). Not sure if the Apple runtime does this. Properties seem to be typesafe KVC. I can't tell exactly how Apple have implemented these. I had some ideas on a very fast way of implementing them that I discussed with Nicolas, but these require modifications to the compiler, rather than the runtime. The nicest part of Objective-C 2.0 seems to be the fast enumerations. Supporting these shouldn't be too hard. Each collection class needs to implement: - (unsigned int)countByEnumeratingWithState:(struct __objcFastEnumerationState *)state objects:(id *)items count:(unsigned int)stackcount; The caller passes on an array of stackcount elements and the callee writes the next few values into the array and returns the number it has written. The caller can then iterate over the next n elements (gcc uses n=16) without calling the method again. struct __objcFastEnumerationState seems to have a single field, containing a number. The object needs to keep track of which enumerations are in progress somehow (not sure how Apple does this). If mutation has occurred, they call objc_enumerationMutation, which calls the function which was set by objc_setEnumerationMutationHandler() which, on Cocoa, just throws an exception. Most of the changes I've spotted in a cursory glance over the header seem to be making the Apple runtime more similar semantically to the GNU one (apparently someone noticed it's impossible to implement polymorphic inline caching with the Apple runtime, but trivial with the GNU one...). There are also a number of things that look like they are designed to make things like KVO easier (references to 'class pairs') by making it easier to create proxy classes on the fly (okay, I'm completely guessing here). By the way, I've written a comparison of the new features in Leopard to the new stuff in Étoilé here: http://www.etoile-project.org/etoile/blog/2007/10/objective-c-toil-vs-leopard.html David P.S. Who is the current maintainer of the GNU runtime. I wrote some code for supporting prototypes in the GNU runime which I would like to push upstream at some point. _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
