Re: [SCM] Debian package checker branch, master, updated. 2.5.2-11-g39af0d7
On Aug 13, 2011, at 23:57, Niels Thykier wrote:
> 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.
Yeah, this is exactly what perl does. The sigil is meant to be the mnemonic,
so you know that "$" is scalar and "@" is array.
> 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.
It looks like in this case the second $checks is actually a reference to a hash.
More: http://oreilly.com/catalog/advperl/excerpt/ch01.html
> 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. :)
Perl has a rich set of datatypes, that URL above describes most of those that
you'll run into, i.e. scalars, arrays, hashes and references to all three.
Regards,
Jeremiah
Reply to: