[Top][All Lists]

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

Re: ANN: One Step to GNUstep - pre-release version 0.9

From: Gregory Casamento
Subject: Re: ANN: One Step to GNUstep - pre-release version 0.9
Date: Mon, 13 Jun 2011 17:18:58 -0400

On Mon, Jun 13, 2011 at 2:41 PM, Riccardo Mottola
<riccardo.mottola@libero.it> wrote:
> Hi,
> I initially avoided jumping into this thread...because it considerably
> diverts from the comments about a release of the virtual machine image to
> the status of GNUstep, a point where we often argue about.
> However since I had already personal chats again about this matter, I will
> express my view in public. They are my opinions, as a long time developer,
> user and enthusiast of GNUstep and as a (former) Mac enthusiast. No more, no
> less.
>> Anyone coming from OS X or iPhone development is going to expect either
>> clang, or a compiler with equivalent functionality to clang.  Giving them an
>> Objective-C environment that is just about at feature party with OS X 10.4
>> does not give the best impression of GNUstep.
> And? They may expect, let them expect! DO I have a binding contract with
> them? Is GNUstep some kind of porting tool at the convenience of any Mac
> developer?

Expecting users to adapt to GNUstep is a short sighted and pompous
view of the world.  This approach has not worked for us whatsoever.
The fact of the matter is that GNUstep is currently short of
developers and users.   We stand a better chance of getting users if
we appeal more directly to Mac and iPhone users.

> That's not my view of the project. I want a powerful framework which can
> support and produce useful Applications in the free software world, thus
> Linux, BSD and which is capable of running on other hosts as well like Hurd,
> Solaris, Windows and others

This is simply not how GNUstep started out.  GNUstep's purpose was to
be an OpenStep implementation and I believe that is still our purpose,
except that we should be compliant with the current version of
OpenStep which happens to be Cocoa.

GNUstep's original intent was to provide a porting environment AND a
development environment and that goal HAS NOT CHANGED to my knowledge
in the past few years.

> Of course, when implementing stuff, it is a good thing to be compatible with
> Apple, to ease code reuse. But Since I dislike more and more the direction
> of Apple's software, why should GNUstep follow them? ON the other side Apple
> has a lot of cool stuff I want too!
> So APple may be an inspiration.

Your personal dislike of Apple is irrelevant to the success of this
project as a whole.   The direction you are thinking of would make us
some mutant offspring of OpenStep/Cocoa which is useful to almost no

> As Nicola writes... if I want an Apple I buy an Apple, not a Pear or a
> Lemon. Are KDE and GNOME clones of Windows or CDE? Much less than we are of
> Mac! They are often heavily inspired.
> We can do better of course, we have more interesting premises, but that's
> it.

I don't agree with this.   Why even bother with GNUstep if this is
your sentiment.  Why not simply create something which is ObjC based
and is completely different and not even bother with compatibility at
all?   Change the names of the classes to something else because
having NS in front of them clearly implies that they are meant to be
compatible with Apple's implementation.

>> Some people may wish to have GCC support as well. I've recently stopped
>> testing everything with GCC, as the lack of features means that I can no
>> longer build significant portions of my code with it (anything that requires
>> the non-fragile ABI or blocks, and anything that needs to interoperate with
>> code using GC), although I still try to test code that only uses ObjC 1
>> features with GCC 4.2.1 (the last GPLv2 version - the license change means
>> that I will probably never see more recent GCC in the FreeBSD base system -
>> FreeBSD 9 is expected to ship with Clang and GCC, FreeBSD 10 with just
>> Clang).
> I want my code to work from gcc 2.95 upwards! Including clang.

There is no problem with this unless it becomes an issue with
including new features.  In which case, and this has been state
before, those interested in keeping such compatibility are tasked with
making the necessary changes to make it work... barring, of course,
reversion of changes to do so.   In other words.... reversion of a
change you don't agree with just because it doesn't work on gcc 2.95
does not qualify as a "fix."

> Riccardo


Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)

reply via email to

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