From: Jakub Narebski <jnareb@gmail.com>
To: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>
Cc: Petr Baudis <pasky@suse.cz>,
git@vger.kernel.org, Christian Couder <chriscool@tuxfamily.org>
Subject: Re: [PATCH GSoC 1/3] gitweb: Create Gitweb::Config module
Date: Thu, 3 Jun 2010 20:43:13 +0200 [thread overview]
Message-ID: <201006032043.14071.jnareb@gmail.com> (raw)
In-Reply-To: <AANLkTimoA95U0vivTzrc0XZ8i6q-SfCFA6RgMWK67OWl@mail.gmail.com>
Pavan Kumar Sunkara wrote:
> 2010/6/3 Jakub Narebski <jnareb@gmail.com>:
>> On Tue, 3 Jun 2010, Petr Baudis wrote:
>>>> +
>>>> +use Gitweb::Config;
>>>>
>>>> BEGIN {
>>>> CGI->compile() if $ENV{'MOD_PERL'};
>>>> }
>>>>
>>>> -our $version = "++GIT_VERSION++";
>>>> +$version = "++GIT_VERSION++";
>>
>> This change is not necessary.
>>
>> our $version = "++GIT_VERSION++";
>>
>> would keep working even if '$version' is declared in other module and
>> exported by this module (is imported into current scope).
>
> Ok. Will change it.
[...]
>> I would say
>>
>> our $GIT = "++GIT_BINDIR++/git";
>
> But, I think when we start reading the code, it would seem that 'our
> $GIT' implies that it is a variable created locally rather than an
> exported variable from Gitweb::Config module.
From `perldoc -f our`:
An "our" declares the listed variables to be valid globals within the
enclosing block, file, or "eval". That is, it has the same scoping
rules as a "my" declaration, but does not create a local variable.
[...] The package in which the variable is entered is determined at
the point of the declaration, [...]
So if the variable already exists in given scope, for example if the
variable was imported from other package, the 'our' declaration would
be a no-op.
>
> Even though it increases the patch size, I don't think it will be much
> of a concern when it comes to good redability of code.
>
> Jakub: Can you reply, what you think about this argument ?
But I agree that first, 'our $var' seems to imply that it is _new_
variable declared in current scope, and second if we make a typo in
variable name it wouldn't be detected as different from exported
variable: 'our' will create new variable.
So I agree that removing 'our' is a good idea, especially together
with putting all variables that should be there in Gitweb::Config
together with comments, even if they are configured during build
process.
Perhaps those declarations in Gitweb::Config should have in-line
comment that they are defined in gitweb.cgi / gitweb.perl?
--
Jakub Narebski
Poland
next prev parent reply other threads:[~2010-06-03 18:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-03 13:55 [PATCH GSoC 1/3] gitweb: Create Gitweb::Config module Pavan Kumar Sunkara
2010-06-03 13:55 ` [PATCH GSoC 2/3] gitweb: Create Gitweb::Request module Pavan Kumar Sunkara
2010-06-03 13:55 ` [PATCH 3/3] git-instaweb: Add support for --reuse-config using gitconfig Pavan Kumar Sunkara
2010-06-03 15:20 ` [PATCH GSoC 1/3] gitweb: Create Gitweb::Config module Petr Baudis
2010-06-03 15:54 ` Ævar Arnfjörð Bjarmason
2010-06-03 16:59 ` Jakub Narebski
2010-06-03 17:04 ` Ævar Arnfjörð Bjarmason
2010-06-03 15:55 ` Jakub Narebski
2010-06-03 16:06 ` Petr Baudis
2010-06-03 16:11 ` Pavan Kumar Sunkara
2010-06-03 18:43 ` Jakub Narebski [this message]
2010-06-03 18:50 ` Pavan Kumar Sunkara
2010-06-03 16:00 ` Ævar Arnfjörð Bjarmason
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=201006032043.14071.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=pasky@suse.cz \
--cc=pavan.sss1991@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.