On 9 Jan 2006, at 06:31, Sheldon Gill wrote:
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*.
OK ... but we need to be sure what we are talking about and what the
reasons are ...
Are you against the principle of allowing args/environment to be
overridden programatically, or against the specific implementation?
We also need to know why this is currently being done by at least one
person (wish I could remember who it was), who presumably is of the
opinion that it *is* a good feature.
I can invent obscure setups where this would obviously be very
useful ... but I don't know which actually apply.
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.
A significant minority will ... anyone embedding gnustep code inside
other software written in another language or without main() being
available for some other reason (eg an apache module) for instance.
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?
Yes, but I can see that there are lots of situations (fitting code
into other software frameworks) where that might be inconvenient
(perhaps completely impractical for all I know).
I think on balance, I'm in favour of the principle of allowing
programmatic override of ars/env ... (since we *must* have a
mechanism to provide args/env for lots of uses, and allowing that
mechanism to override the default setup is not a very complex
extension), but I would prefer a better implementation.
IMO if we go down that route, we should provide a function to do it
and remove the method of NSProcessInfo ... so it can be done easily
from other languages and *before* the objc runtime and any classes
are initialised. That would allow code inside the base library to
access the environment in a consistent way.
We should also change the existing code to work around the current
problem that the C-string characterset we use is determined by an
environment variable, but we don't know how to parse the environment
variables until we know the characterset we are using... in this
respect the current windows code is better than the unix code ... we
use the unicode api to get the environment and therefore don't need
to worry about converting from a C-string.
_______________________________________________
Bug-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnustep
