discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Chisnall
Subject: Re: Objective-C 2.0 and other new features in Leopard
Date: Tue, 30 Oct 2007 01:25:21 +0000


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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]