On Thu, Nov 22, 2007 at 11:32:16PM -0600, Dan Zwell wrote:
> Further, I think that we could return the default variable directly, without
> parsing it at all. It would be much simpler, and there would need to be no
> special cases for dealing with undef or 'false'. It's a perl function, being
> called with perl arguments, so a user should not be that surprised when
> 'false' does what perl says it should do.
I think that is more elegant for config_bool, but it means that
config_bool and config_color have slightly different behaviors (the
difference being that it is easy to feed a native perl value as the
default to config_bool, but to get the same behavior for config_color,
you would call Git::color_to_ansi_code manually, which is a pain).
In this instance, I am inclined to sacrifice consistency for convenience
and make it:
my $bool = config_bool('my.key', 0);
my $color = config_color('my.key', 'bold red');
Note that there is one tricky part of config_bool, which is what
config_bool('my.key', undef) should do (is it "default false" or "no
default"?).
-Peff
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
