[Top][All Lists]

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

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

From: Quentin Mathé
Subject: Re: Objective-C 2.0 and other new features in Leopard
Date: Tue, 30 Oct 2007 00:46:21 +0100

Hi Gregory,

Le 27 oct. 07 à 01:58, Gregory John Casamento a écrit :


As many of you are probably aware, Apple released Leopard today.
Leopard contains a number of enhancements which are important to us, one of which is Objective-C 2.0.

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.

I think it depends on the code Apple will submit back to GCC.
Apple seems to be slowly moving away from GCC in favor of LLVM. From what I read, Xcode 3 uses LLVM to support ObjC refactoring. A new experimental C/ObjC front-end named clang was released as part of LLVM 2.1 (see <http://clang.llvm.org/>). Both clang and LLVM looks very promising.

If adding ObjC 2 support to GNU runtime in FSF GCC context proves to be complicated, it could be simpler to add GNU runtime support to clang. It could also be helpful in future seeing that Apple will probably switch to LLVM for C, ObjC and C++ in next Mac OS X release.

Interface Builder enhancements
The other feature which is interesting in it is the ability of InterfaceBuilder to support multiple languages including Ruby. The recursive descent parser I wrote for Gorm currently only handles Objective-C headers. Additionally, Gorm's internal data structures are decoupled from the type of archive that is being saved or read, nib, or gorm. When I added the nib support I rewrote nib/gorm support in both gui and in Gorm to support an architecture that allows classes which read/write different types of gui files to register themselves so that they would be considered when a gui model is loaded.

Yesterday night, I spent some time dipping into new developer documentation and API. Interface Builder seems to have been massively rewritten. In addition to what you already mentioned, the interesting stuff seems to be:
- new UI
- new nib format (version 3) and new xib format (text-based format to better integrate with SCM) - new IB palette API replacing the previous one <http:// developer.apple.com/leopard/devcenter/docs/documentation/ DeveloperTools/Reference/InterfaceBuilder_framework/index.html> <http://developer.apple.com/leopard/devcenter/docs/documentation/ DeveloperTools/Conceptual/IBPlugInGuide/index.html>

I am planning on moving Gorm to a more bundle/plugin oriented architecture in the future. This has a number of implications:

Gorm will be able to:
1) parse multiple languages

Would be nice.

2) generate multiple languages (for class files)
3) read/write any type of gui model for which it has a plugin available
    * gorm
    * nib
    * gmodel... etc

I'm specially interested by such public API. I have begun to work on a new GUI model that can describe composite documents and UI in the same format. I would like to be able to load and save this model directly (in Gorm and in applications) rather than generating it from GNUstep view hierachy on nib loading.


Quentin Mathé

reply via email to

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