Qualified module variables and arrays

[DarrenSol]

Thanks for the advice and comments on my previous question on arrays in modules. I have that working, but of course, I have another question :) I'm wondering just how necessary it is to use a qualifier on a module-declared variable or array.

I understand (to some extent) qualifying the names of variables and arrays declared in modules, when accessed in a script. It seemed awfully cumbersome to me to use the qualified names, but I went at it.

While making those changes to a script, I used a module variable reference to access a module array, but forgot to add the qualifier. I didn't notice the missing qualifier until going over the script to add comments. I checked through the script and module and didn't find it malfunctioning.

So I got to thinking : would it work without the qualifier in other situations ? So far, it does.

As a test case, I modified a short script without the qualifiers, instead using an abbreviation of the subroutine name, like this:

OpenFileFillWeeklyTimeArray::$WeeklyTimeArrayRef

became

$OFFWTA_WeeklyTimeArrayRef

So far, in testing, it works. The abbreviation-prefixed name tells me right off this isn't a local variable - don't modify it or the array it references. This type of name also takes up half the space of the qualified name. And I find it easier to read the script, without the cumbersome qualified name.

But I know enough to know I don't know what I don't know.

So I'm asking here: Am I letting myself in for considerable grief down the road using this naming convention for module variables and arrays ?

[trippledubs]

In the beginning of a Perl Romance, your skills will get better every hour you spend learning and writing perl, similar to Moore's law. So, every time you look back at your past work, you are always disappointed. The beauty and nature of Perl is so that, you will solve your problem now, and that is a beautiful thing, and you will also recognize more problems that Perl can solve and will keep coming back.

It is always best to post some compilable code here so we get an idea of the context of your question. Here are some random ways to call subroutines and I think the pitfalls become evident of bad design choice. The principles are: have very descriptive and appropriate variable names, and keep your namespace as uncluttered as possible. And, as in life, always do whatever you want. Counter example follows

#!/usr/bin/env perl
package a;
use strict;
use warnings;
use lib (',');

sub double {
  return 2*$_[0];
}


package main;
use strict;
use warnings;
use feature 'say';
use Cowbell qw(thrice);

sub double {
  return "$_[0]" . $_[0];
}

sub twice {
  return a::double($_[0]);
}


say a::double(2); #4
say double(2);  #22
say thrice(2); #6

say thrice(2) - twice(3) + double(22) + 1;

#!/usr/bin/env perl
package Cowbell;
use strict;
use warnings;
use Exporter 'import';
our @EXPORT_OK = qw (thrice);

sub thrice {
  return 3*$_[0];
}

[choroba]

OpenFileFillWeeklyTimeArray::$WeeklyTimeArrayRef is not the correct way how to fully qualify a variable. Use

$OpenFileFillWeeklyTimeArray::WeeklyTimeArrayRef

Without seeing your code, I can't say how Perl discovered that $OFFWTA_WeeklyTimeArrayRef is the same as $OpenFileFillWeeklyTimeArray::WeeklyTimeArrayRef (or at least, as references, their references are the same). Generally, it doesn't work:

#!/usr/bin/perl
use warnings;
use strict;

{   package SomeVeryLongPackageName::ToBeBoringToType;

    our $PackageArrayRef = [];

    sub init {
        push @$PackageArrayRef, localtime, @_;
    }

}

our $SVLPNTBBTT_PackageArrayRef; # How did you tell Perl this is the s
+ame ref?

SomeVeryLongPackageName::ToBeBoringToType::init(1);
print join "\n", @$SomeVeryLongPackageName::ToBeBoringToType::PackageA
+rrayRef;
print join "\n", @$SVLPNTBBTT_PackageArrayRef;

[Laurent_R]

I think that using qualified variable name should be done very rarely, only for very specific cases. What you usually want to do with a module is to have the mudule functions to receive the arguments neccessary for its processing and returning the values expected by the caller. This is much cleaner than sharing values or using global variables, because the module function becomes a blackbox that you don't have to worry about any longer: it receives some arguments and returns somez expected values, you don't have to worry about how it works, or whether some other variable or environment needs to be set beforehand.

[AnomalousMonk]

Further to trippledubs's reply (update: and choroba's reply):   DarrenSol: You say, in effect, "I wrote some code and then wrote another version of that code. Both versions seem to work. Please tell me which version is to be preferred and why, but I'm not going to show you either version! Many thanks in advance."

IMHO, what you need to do is provide us with two (or more!) small, self-contained, compilable and executable code examples that we can all ponder and discuss. We may then be able to provide you with advice for which you can thank us!

[Anonymous Monk]

Um, I think you need to read all these Tutorials: Variable Scoping in Perl: the basics,
Coping with Scoping , Mini-Tutorial: Perl's Memory Management,
Lexical scoping like a fox,
Read this if you want to cut your development time in half!,
zentara package/module tutorial