[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSPathUtilities Patch
Re: NSPathUtilities Patch
Wed, 21 Apr 2004 15:34:39 +0200
I have looked shortly at your patches.
So I have not a really clear idea where this is going, but
I don't think the patches are in a state yet that they
can be applied. My concerns are on a detailled level
as well as on a more philosphical level.
* Patches introduce quite a lot of outcommented code
* Introduce a few functions that are not used anywhere
* Make new header files public without apparent reason
* Put lots of #pragma mark - code in files (what is it
* Why do most new win32 functions take a cString as
argument ant return an NSString, instead
of taking an NSString
* Why do you call CoCreateInstance in the Win32_Utilities_init
function. It seems to initialize the windows COM
system, but what does that have to do with GNUstep?
* Why do you expect these windows functions to be needed
from "gui" as well?
* Capitalization is inconsistency, test_assign macro is
* I think there are retain count problems in
gnustep_rc_filename is set to the value of
objectForKey:, while os_sys_prefs is set to
objectForKey: but retained.
* Probably more, but I stopped looking
* If you want to get rid of the necessity to specify
GNUSTEP_SYSTEM_ROOT and other environment variables.
Why not figure out the path of the gnustep-base.dll
(or on linux libgnustep-base.so) when starting up
and use that as a reference point to provide
default values for the paths.
* What is the idea behind the PLATFORM_... paths?
It seems to me that this will lead to
different behaviour on different platforms.
I do not think it is desirable to provide
something that only works differently
on different platforms.
* In the same category, the NSTemporaryDirectory change.
It should be clear what the programmer can
expect from this path. And it should be the
same on all platforms. (or as close to same
as possible.) I think it does this, but the
sentiment in the documentation that if you
want the old behaviour there are workarounds
is not very encouraging.
To consolidate my take on it.
GNUstep should be as platform independ as possible, that
means, NO visibility to the programmer of platform specific
options. The programmer is of course free to use platform
specific stuff, but it should not be provided by GNUstep.
This is not to say that I really would like to see a better
approach to the startup/installation of GNUstep.
But I agree with other people on the list
that it should be split in independ patches.
|[Prev in Thread]
||[Next in Thread]|
- Re: NSPathUtilities Patch,
Wim Oudshoorn <=