From: Petr Baudis <pasky@suse.cz>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org, Lea Wiemann <lewiemann@gmail.com>
Subject: Re: [RFC/PATCH (WIP)] Git.pm: Add get_config() method and related subroutines
Date: Wed, 9 Jul 2008 18:03:03 +0200 [thread overview]
Message-ID: <20080709160303.GL10151@machine.or.cz> (raw)
In-Reply-To: <200807031824.55958.jnareb@gmail.com>
Hi!
On Thu, Jul 03, 2008 at 06:24:53PM +0200, Jakub Narebski wrote:
> There are also a few things which I'd like some comments about:
>
> * Do config_val_to_bool and config_val_to_int should be exported
> by default?
Yes with the current API, not with object API (see below). But if
exported by default, there should be definitely a git_ prefix.
> * Should config_val_to_bool and config_val_to_int throw error or
> just return 'undef' on invalid values? One can check if variable
> is defined using "exists($config_hash{'varname'})".
I think that it's more reasonable to throw an error here (as long as
you don't throw an error on undef argument). This particular case is
clearly a misconfiguration by the user and you rarely need to handle
this more gracefully, I believe.
> * How config_val_to_bool etc. should be named? Perhaps just
> config_to_bool, like in gitweb?
What about Git::Config::bool()? ;-) (See below.)
> * Is "return wantarray ? %config : \%config;" DWIM-mery good style?
> I am _not_ a Perl hacker...
I maybe wouldn't be as liberal myself, but I can't tell if it's a bad
style either.
> * Should ->get_config() use ->command_output_pipe, or simpler
> ->command() method, reading whole config into array?
You have the code written already, I'd stick with it.
> * What should ->get_config() have as an optional parameter:
> PREFIX (/^$prefix/o), or simply SECTION (/^(?:$section)\./o)?
Do we even _need_ a parameter like that? I don't understand what is
this interface trying to address.
> * Should we perltie hash?
I agree with Lea that we should actually bless it. :-) Returning a
Git::Config object provides a more flexible interface, and you can also
do $repo->get_config()->bool('key') which is quite more elegant way than
the val_ functions, I think. Also, having accessors for special types
lets you return undef when the type really isn't defined, instead of
e.g. true with current config_val_bool, which is clearly bogus and
requires complicated code on the user side.
> As this is an RFC I have not checked if manpage (generated from
> embedded POD documentation) renders correctly.
By the way, unless you know already, you can do that trivially by
issuing:
perldoc perl/Git.pm
--
Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson
next prev parent reply other threads:[~2008-07-09 16:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-03 16:24 [RFC/PATCH (WIP)] Git.pm: Add get_config() method and related subroutines Jakub Narebski
2008-07-03 20:30 ` Lea Wiemann
2008-07-03 23:45 ` Jakub Narebski
2008-07-07 19:24 ` Lea Wiemann
2008-07-09 15:23 ` Petr Baudis
2008-07-09 16:03 ` Petr Baudis [this message]
2008-07-09 23:33 ` Jakub Narebski
2008-07-12 1:47 ` Petr Baudis
2008-07-12 12:35 ` Jakub Narebski
2008-07-12 13:45 ` Petr Baudis
2008-07-12 14:31 ` Jakub Narebski
2008-07-12 18:05 ` Petr Baudis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080709160303.GL10151@machine.or.cz \
--to=pasky@suse.cz \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
--cc=lewiemann@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).