[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [SCM] Debian package checker branch, master, updated. 2.5.2-11-g39af0d7



On 2011-08-13 23:13, Russ Allbery wrote:
> "Niels Thykier" <niels@thykier.net> writes:
> 
>>     Perlcritic cleaned c/standards-version
> 
>> -our $STANDARDS = Lintian::Data->new('standards-version/release-dates', '\s+');
>> +my $STANDARDS = Lintian::Data->new('standards-version/release-dates', qr/\s+/o);
> 
> These are file globals -- why would one use my instead of our?  Do you
> know what the rationale of perlcritic is here?
> 
>> -our $CURRENT   = $STANDARDS[0][0];
>> -our @CURRENT   = split(/\./, $CURRENT);
>> +my $CURRENT_VER = $STANDARDS[0][0];
>> +my @CURRENT     = split(m/\./, $CURRENT_VER);
> 
> *grumble*.  This is one of the reasons why I don't particularly like
> perlcritic.  Those two variables contain exactly the same information,
> just in one case as a string and in another case as an array, which you
> can represent in Perl with the same variable name as a scalar and as an
> array.  Using different variable names for them is obfuscating, not adding
> clarity.
> 
> I don't really care that much, and I'm all in favor of picking a coding
> style and following it uniformly even if it isn't the one I'd choose, so
> I'm not saying to change this back.  But I do think perlcritic is wrong
> about this.
> 

Turns out this particular these two were not Perlcritic issues (I
applied these fixes from my memory of previous Perlcritic issues).
  So the "my vs. our", I seem to have confused "our" with "use vars"  in
terms of Perlcritic warnings.  As for "my vs. our", it is my
understanding that "our" makes the variable "public"[0] and it seems to
me these variables are not actually intended to be used outside of
checks/standards-version.

On the other issue, I thought the "$C, @C"-thing was covered by the
"re-use" of same variable in lexical scope, but it turns out it isn't
(probably due to the "types" being different).
  I can see the idea behind it now, sort of like a C-string where you
can process the string as a whole (strcmp(s, "text")) or individual
characters (s[0]).  I guess the perl way of doing that is to declare two
variables with same name and different type.
  In the given case I can see the use of this.  That being said, I have
my concerns blessing wide-spread use of this.  You may remember I got a
bit confused with:

"""
$checks or ($checks = join(',',keys %check_info));
[...]
$checks{$c} = 1;
"""
 from frontend/lintian in 2.4.3: $checks was a comma-separated list and
%checks was a hash where the keys were elements from said list.

Can you point me to the section on "my ($v, @v, %v);" in the perl
documentation (not really sure what to look/google for here).  I would
like to get a second look on this. :)

~Niels

[0] That is I could do something like
"$Lintian::standards_version::CURRENT" from a different file.


Reply to: