Re: [boost] Environment Variables Library?

Subject: Re: [boost] Environment Variables Library?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-05-22 04:59:13

On Friday 22 May 2015 18:35:09 Michael Ainsworth wrote:
> > Note that not only paths can be present in multi-element env. variables.
> > For example, LS_COLORS contains a list of color specifications for ls
> > command. I think, it's better for the environment library to perform a
> > split to a sequence of strings and let the user interpret those strings
> > as filesystem paths or something else.
>
> Exactly. $PATH isn't the only "array-like" variable, hence my reasoning for
> encapsulating the raw name/value string pair in a 'variable' class that can
> iterate over the substrings in the value string. It may be confusing
> though. Will think more on it.

I think it's better to have a separate interface for splitting/joining - 
preferably, an algorithm (a free function).

I'm not sure a 'variable' class which contains both name and value is a good 
thing, at least as the main interface. When I get a variable, I expect to have 
to pass only its name and receive only its value, like:

  std::string value = env["FOO"];

Also, common operators become either unclear or confusing on the 'variable' 
class:

  variable var1, var2;
  var1 = var2; // assigns value or both name and value?
  var1 == var2; // compares value or both name and value?

And certainly I don't think it's a good idea to collect algorithms in the 
'variable' interface, like it's done in std::string.

> Do all variables on the one platform have the same separator?

There are application-specific variables that contain different separators but 
I don't think you have to support them in your library. You can, however, 
provide the separator argument to the splitting/joining algorithms, which by 
default would be the system-specific default. It would be nice if that default 
could be visible by user (e.g. as a character constant) if he wants to do some 
string processing himself.