On Thu, 23 Oct 2014 15:27:50 +0100, Leandro Lucarella <l...@llucax.com.ar> wrote:

Regan Heath, el 22 de October a las 10:41 me escribiste:
>NO, this is completely false, and why I think you are not entirely
>familiar with env vars in posix. LD_PRELOAD and LD_LIBRARY_PATH affects
>ALL, EACH and EVERY program for example. D or not D. Every single
>dynamically linked program.

True.  And the reason these behave this way is because we *always*
want them to - the same is NOT true of the proposed vars for D.

No, not at all, you very rarely want to change LD_PRELOAD and
LD_LIBRARY_PATH globaly.

Sure, but when you do change them you will want them to propagate, by default, which is why envvars are used for these.

The same is not true of many potential D GC/allocation/debug flags, we do not necessarily want them to propagate at all and in fact we may want to target a single exe in a process tree i.e.

parent     <- not this
  child1   <- this one
    child2 <- not this

My conclusion is we don't agree mainly on this:

I think there are cases where you want runtime configuration to
propagate or be set more or less globally.

I agree that there are cases we might want it to propagate *from a parent exe downwards* or similar but this is not what I would call "more or less globally" it's very much less than globally. The scope we want is going to be either a single exe, or that exe and some or all of it's children and possibly only for a single execution.

Sure, you *could* wrap a single execution in it's own session and only set the envvar within that session but it's far simpler just to pass a command line arg. Likewise, you could set an envvar in a session and run multiple executions within that session, but again it's simpler just to pass an arg each time.

Basically, I don't see what positive benefit you get from an envvar over a command line switch, especially if you assume/agree that the most sensible default these switches is 'off' and that they should be enabled specifically.

I think what we disagree about here is the scope it should apply and whether propagation should be the default behaviour.

You think no one will ever want some runtime option to propagate.

Nope, I never said that.

Also, I don't have much of a problem with having command-line options to
configure the runtime too, although I think in linux/unix is much less
natural.

Surely not, unix is the king of command line switches.

Runtime configuration will be most of the time some to be done
either by the developer (in which case it would be nicer to have a
programatic way to configure it)

Agreed.

or on a system level, by a system
administrator / devops (in which case for me environment variables are
superior for me).

Disagree. It's not something we ever want at a system level, it's somewhere within the range of a single session <-> single execution.

Usually runtime options will be completely meaningless
for a regular user. Also, will you document them when you use --help?

Or course not, just as you would not document the envvar(s).

R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Reply via email to