Re: Objective-C 2.0 and other new features in Leopard

[David Chisnall]

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.