CultureAttribute for interpreting culture specific input about commandline

[gsscoder]

@isolaol, I'm very glad that you liked my work and that it helped you. There's a lot of features scheduled for next releases -> to remove command-line-parsing related task from developers code and re-use it through the library (promoting code-reuse).

The culture issue is well known to me, as stated [here (https://github.com/gsscoder/commandline/wiki/Advanced-Topics).

Thanks for valuable comments, I'll carefully examine everything.

But if I've to give an opinion immediately, I'd like to solve the problem introducing the actual default (thread based) in IParserSettings instance and let developers overwrite the value

An example:

var parser = new CommandLine.Parser(with =>
  with.UseCulture(CultureInfo.InvariantCulture)
);
// or
var parser = new CommandLine.Parser(new ParserSetting {
  Culture = new CultureInfo("en-US")
});

Actually I can't change settings for the default (CommandLineParser::Default) singleton. But it's possible that I'll introduce this breaking change in next stable (maybe on 2.* branch); that is settings invariant culture as default.

Thanks for participating in the project!

Regards,
Giacomo Stelluti Scala

[gsscoder]

Now you can set it via IParserSettings::ParsingCulture as explained here.

[isolaol]

Hi gsscoder,

Thanks for your modification, it has credit of its own! I am delighted that you have time and devotion to develop the library.

Unfortunately, I feel that I failed to make my point clear. So, I try to explain the idea again for your consideration.

Now, the culture of the parser is set before calling ParseArguments(). It's a decision made by a programmer. A programmer may not know (or does not want to dictate) which culture is used or should be used to pass values from command line to the program.

The idea of the CultureAttribute is to provide the caller of the executable means of setting parser culture case by case! This inevitably leads to two-phase parsing process:

1. scan argument list if there are -c (or --culture) option
2. change parser culture to the one specified in -c (or --culture) option
3. proceed with normal parsing because we know the correct culture, now

CultureAttribute would indicate which option will act as such modifier.

This is the process I would like to move from main procedure to the library.

Kind regards,
Olli-Pekka Isola

[gsscoder]

Dear @isolaol,
the need to make such modification (already in my TODO list) make me overlook what you effectively said!

Sorry... :D

We can re-open, off course.

[gsscoder]

I want to add, @isolaol, that the feature request is FULLY understood / approved and may be implemented as possible.

At the moment is scheduled in the new branch (develop) that will be created after release the next (upcoming) stable.

Regards,
Giacomo

[isolaol]

Sure,

Here comes...

In the normal case (when Permanent=False), culture specified should not
change the CurrentCulture setting of the CurrentThread. Instead, the
culture setting passed from command line should be fed to conversion
methods as a second parameter. Take a look at Convert.ToDouble(string,
IFormatProvider) as an example.
http://msdn.microsoft.com/en-us/library/9s9ak971.aspx

In some cases, the programmer may want to delegate (when Permanent=True)
the configuration of the CurrentThread.CurrentCulture to the commandline
library. In this case, library can also change the value of
CurrentCulture to the one passed via command line.

Permanent = False: Apply culture setting when parsing command line but
do not change CurrentThread.CurrentCulture value in the end of parsing
process. The programmer controls the value of the
CurrentThread.CurrentCulture.

Permanent = True: Apply culture setting when parsing command line and
change CurrentThread.CurrentCulture value in the end of parsing process.

You may come up with some other parameter name, Temporary, for example
(Temporary = !(Permanent)). Or leave it away for now, if programmer can
read the culture passed from command line. (Since programmer can read
the value and set CurrentThread.CurrentCulture himself/herself.)

BR, Olli-Pekka

[isolaol]

The short note: I think that it's better to set
CultureAttribute::Permanent default to False. Or in case you prefer
"Temporary", the default value should be True. As a result, culture
setting will affect string conversions during the parsing process but
does not ruin main thread CurrentCulture if programmer does not
specifically want it. ;-)

BR, Olli-Pekka

[gsscoder]

@isolaol

Thanks for clarification. Agree Permanent = false. I'm also in doubt if it's correct to allow that a library mutate permanently this setting.

We could also remove this property and when (after culture-based parsing) if the developer wants can read the culture do what he want.

A sort of single-responsibility principle extended to the whole library whose responsibility is just pursing the command line, not change the culture (also if this could be useful). What do you think?

As said, I'm about to promote code to stable. I'll advice here when new branch with this enhancement will be created. You'll able to test it in the develop branch and add comments.

Regards, Giacomo

[isolaol]

I agree with you, Giacomo. It's better to leave Permanent/Temporary
functionality away from CultureAttribute. The programmer can any time read
the value of CultureAttribute and mutate CurrentThread.CurrentCulture.

BR,
Olli-Pekka

------- Original message -------

From: Giacomo Stelluti Scala [email protected]
To: [email protected]
Cc: [email protected]
Sent: 24.2.'13, 21:00

@isolaol

Thanks for clarification. Agree Permanent = false. I'm also in doubt if
it's correct to allow that a library mutate permanently this setting.

We could also remove this property and when (after culture-based parsing)
if the developer wants can read the culture do what he want.

A sort of single-responsibility principle extended to the whole library
whose responsibility is just pursing the command line, not change the
culture (also if this could be useful). What do you think?

As said, I'm about to promote code to stable. I'll advice here when new
branch with this enhancement will be created. You'll able to test it in
the develop branch and add comments.

Regards, Giacomo

Reply to this email directly or view it on GitHub.

[gsscoder]

👍 ok

[gsscoder]

Work is not stopped, please read https://github.com/gsscoder/commandline/wiki/Official-Roadmap

[gsscoder]

I think that pre-rel 2.0 learnt the lesson... Or am I wrong?

If I'm right, can the issue be closed?

cc/ @isolaol

[alexanderfast]

Considering the lack of activity, it's time to close this (just reopen if need be).