Re: Compatibility with OSX

[Nicola Pero]

> >> Also, if you, by accident, set a nil value you program crashes.
> >> Personally I think a GUI library should not do this.
> >> nil is perfectly fine and GNUstep should try to cope with it
> >> as gracefully as it can.  I rather have an empty field
> >> than a crash.
> >
> > The problem is that your program will crash under OS-X.
> >
> > So, when you'll port your app to OS-X (if you do), you'll end up trying
> > to find where your do your setValue: nil and you'll fix that in your
> > code to prevent this. That's awkward because you could have seen that
> > problem right away under GNUstep.
> >
> > We want OS-X compatibility and this change is to make porting your app
> > easier to OS-X.
> 
> That's actually a very poor justification for it ... we have debug 
> logging
> macros/functions to deal with this sort of case.  In the past our 
> principle
> has been to try our best to keep the program running, but when built for
> debug, generate warnings when there are MacOS-X incompatibilities like 
> this.
> 
> Generating a warning message is just as useful for maintaining 
> compatibility
> as crashing is, but carrying on running is much better for people who do 
> not
> care about porting to MacOS-X

Thanks - very good point - I changed it to use NSWarmMLog ... 

Ideally, I'd have liked to use NSDebugMLog (so that it doesn't get
compiled with debug=no, and you have to manually turn on debugging to see
the warning - I personally like setStringValue: to accept nil and don't
want the library to warn me if I use it that way), but then Ludovic to see
the warning would have had to use --GNU-Debug=dflt, and that turns on so
many messages about gnustep-gui internals I doubt it's a good idea to tell
application developers to use that ... it's meant to debug the gui library
itself, not to warn about possible unsafe/unportable code in applications
... so I used NSWarnMLog.

Let me know if you know a better macro for it (/change it yourself if you
find the time).