All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.