[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 :
All,
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,
Sure.
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.
Cheers,
Quentin.
--
Quentin Mathé
qmathe@club-internet.fr