|
From: | Richard Frith-Macdonald |
Subject: | Re: [bug #15353] win32 compilation of base fails on NSProcessInfo.m (checked out from CVS today) |
Date: | Mon, 9 Jan 2006 05:51:59 +0000 |
On 9 Jan 2006, at 05:27, Sheldon Gill wrote:
Follow-up Comment #5: I'm fairly sure this is fixed by moving the declaration of fallbackInitialisation. At least ... the current code in CVS compiled and runs fine for meCould you please explain why "fallbackInitialisation" is needed and a good idea?
I'm not at all sure it *is* a good idea.Basically, it arises from a complaint I got from a windows user (can't remember who) when I fixed the NSProcessInfo code for obtaining the environment information to ensure that it got the correct character encoding (using the unicode api ... the original code just assumed that the environment info was in latin1 encoding).
The change broke this persons code ... he was using +initializeWithArguments:count:environment: to specify an environment to which he had added some extra environment variables, and my restructuring with fallbackInitialisation was a quick hack to restore the original behavior where the real environment can be overridden.
Now, the intention of +initializeWithArguments:count:environment: was to supply a mechanism to initialise NSProcessInfo for systems where the base library can't determine args/env automatically, not to override/alter the args/env, so arguably he shouldn't have been using it for that, which is why I'm not sure that continueing to support that behavior is a good idea.
If we *do* want to allow the args/env to be overridden programmatically, we should document the behavior and ensure that it always works.
[Prev in Thread] | Current Thread | [Next in Thread] |