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

[Fred Kiefer]

This is a very optimistic view of things, which I cannot share for the
whole of GNUstep at the moment.

My feeling is the race is over and we lost. Apple has just released a
shining new version of there system and GNUstep is rather stagnant. We
are no longer attracting old or new developers and it doesn't look like
this is going to change. Have a look at the Changelog files from the
last half year and you will understand what I mean. Not even the paid
coders from GSoC made any difference.

We urgently need to change the way GNUstep appears to the outside world,
or we will become as obsolete as now seem. Personally I am thinking
about reducing my involvement with GNUstep. It still is fun to hack way
on GNUstep, but trying to get the library out of its current stagnation
phase would require a bigger effort, which I cannot see at the moment.

Cheers,
Fred

Gregory John Casamento wrote:
> 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, 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. 
> 
> 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.
> 
> 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
> 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
>