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 me
Could 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.
_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep