Re: GNUstep Base OpenStep Compliance

[Nicola Pero]

Tim,

before answering on the specific point, I'd like to thank you for the
useful feedback.  I don't agree with you that OPENSTEP vs Cocoa
compatibility is the cause of such problems in GNUstep's "stability" (as
I'll explain below), but it was still quite useful to have reports that
such problems (and related bad feelings) exist ... :-)

Applications breaking from one release to the other one ... that really
makes me think we should test and think each change carefully.  I've seen
it happening millions of times in gnustep-gui ... someone fixing a bug,
and generally because of lack of understanding of the wider
picture/context, implicitly creating a new (often unrelated) bug.  I think
that's the real issue to address to get more stability - we should focus
on quality as much as we can, particularly when patching existing code.  
Think carefully and inspect changes line by line, and test extensively,
and only apply to CVS stuff which we are 100% sure will improve things,
and break nothing.

>From time to time I also tend to come under the impression that the
ApplicationKit's design is not as good or crystal-clear as the
FoundationKit's one.  Some parts of the ApplicationKit - such as text
editing in cells, keyboard navigation, events handling - are often too
complex - too many classes interacting with each other in complex, subtle
and difficult ways - it becomes sort of a global net where many complex
entities are interacting with each other in subtle ways ... which
generates the problem: you fix a bug "locally", and because it's difficult
to realize the "global" impact of your change (and you can't easily test
parts in isolation, as they don't really make sense out of context), you
actually implicitly generate another bug somewhere else.  In other words,
parts of the ApplicationKit suffer from lack of "localization" and
"encapsulation".  Whether this is unavoidable and forced by the task, or
whether it's a design error, and whether similar frameworks are affected
by similar (possibly bigger) problems, I've never thought about enough to
say.


> [...]
> 
> Does that make it clearer as to why we'd want to focus on 
> OpenStep/OPENSTEP as a basis for development?

... frankly, no, at least not to me.

I still don't see a particular connection between stability, and focusing
on being compatible with Apple Cocoa 10.2 instead of OPENSTEP 4.2.

I have this feeling that the discussion might be too vapourwarish and
vague to be of much use ... loosing a bit of contact with reality.  The
differences in API between OPENSTEP 4.2 and Apple Cocoa 10.2 are pretty
small (for the parts implemented in both), and I don't see them affecting
applications that much.  They definitely never affected *my* software, and
I have quite a while. :-)

The only real, important difference between Cocoa and OPENSTEP I remember
to date is the way they respond to nil or NULL arguments.  OPENSTEP
ignores them, Cocoa raises an exception.

But then, unless we want to go our own way ignoring any compatibility, if
we have to choose, of course we want to be compatible with the newest
framework between the two.

Because OPENSTEP is no longer supported/shipped (having been in practice
replaced by Cocoa), all OPENSTEP 4.2 applications out there will likely be
ported to Cocoa or GNUstep anyway.  If not today, if not in the next
month, in the next year or two.

New Cocoa applications use the Cocoa semantics of course.

So in a few years all applications running on non-GNUstep OpenStep
implementations will use Cocoa's semantics.  If we are interested in
portability, of course we want to use the same semantics.

If you are suggesting that we first implement the OPENSTEP semantics, and
then when we finally realize that all the rest of the world is using a
different semantics, we break our API to switch to the Cocoa semantics,
then you are proposing a plan which does exactly what you want to avoid -
create all apps using a certain API, then break the API forcing an update
of all apps.

In this view, the best we can do to maximize the probability that there
will be no need to change the API in the future in order to keep
compatibility with other systems, is of course to implement the most
recent stable/consolidated API of those systems.

Suggesting to implement the older, deprecated API of the other system is
just making it very likely that we will either never be compatible with
other systems, or be compatible only at the expense of breaking the API at
some point.

Said that, I still think all this issue has got out of hand, and it is
really a minor point which doesn't affect things that much.

In all honesty, having followed the discussion and having thought about it
and discussed in emails about it with people, I feel OPENSTEP 4.2
compatibility is mostly irrelevant for GNUstep's future.  Cocoa
compatibility is the real issue.  I'm open to mediate with other views of
course when writing down GNUstep's Mission etc, but this is my personal
feeling.

Now I'll try to *really* leave this thread :-)

I'd like to thank anyone having taken part, and I very much appreciated
reading other people comments (quite intelligent and well motivated) -
even when in disagreement with my own view.