Richard Frith-Macdonald wrote:
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.
Good, because I'm firmly of the opinion that its *not*.
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.
Perhaps better something supplied as a patch rather than immediately put into
cvs HEAD?
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.
I recall the intention of the method. It can remain a usable method at program
start if the base auto-main stuff is compiled away I guess. (ie force:
main()
{
[NSProcessInfo initialize...]
}
but not many would want that.
If we *do* want to allow the args/env to be overridden
programmatically, we should document the behavior and ensure that it
always works.
The *right* way to over-ride args and env would be to do so in an app-wrapper
and then exec, isn't it?
Regards,
Sheldon
_______________________________________________
Bug-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnustep
