[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



Niels Thykier <niels@thykier.net> writes:

> Turns out this particular these two were not Perlcritic issues (I
> applied these fixes from my memory of previous Perlcritic issues).

Oh!  Okay.  I'm actually surprised on the variable one, as I've seen
things like that from perlcritic before.

>   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.

It does, sort of, in the sense that some other module could access those
variables from inside the namespace for that check, and my does prevent
that.  So I suppose this is more of a style thing.  I always use our for
global constants or things initialized at startup, combined with the
all-caps naming convention.  I'm not sure if there's an official style, or
what's the most common.

I suppose another alternative would be use constant, at least in some
cases, although that creates a sub that then doesn't have a type prefix,
and I think those look kind of strange.  But that may just be because I've
been writing Perl for too long.  :)

> 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).

Ah.  Yes.  Each type of variable has its own separate namespace.

>   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, or at least that's what I've always done in the past.

>   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.

Yeah.  I'm not sure if this is really confusing, or if it's just a
familiarity thing.  I use the same name (but a different type) for any set
of variables that all hold exactly the same contents but in a different
data structure, and use a different variable name if the contents may be
different.

> 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. :)

perldata provides some basic explanation of the different data types, the
namespace separation, and how the data type prefixes work, near the top of
the documentation page.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: