Re: strict.pm

[dsb]

Very much enjoyed your review. I do, however, have some questions.

1. I understand the idea of a symbolic reference, but I'm not sure how you'd go about creating one. I'd like to know that so I can avoid it. Might it be something like this:

$a = "Amel";
$b = \$a;     # $b is a 'hard' reference
$c = $b;      # $c is a 'symbolic' reference?

Is this correct? The perlref docs say that a symbolic ref are names of other variables. So in the case above, is $c a symbolic ref because it merely holds as its value another variable that is a hard ref. Or is $c just a deeper hard ref?

2. I looked up 'strict' in the Camel book and it said: "If no import list is given to use 'strict;', all possible restrictions upon unsafe Perl constructs are imposed." My question is: What exactly is an unsafe construct, and what is it that makes it unsafe?(OK that's 2 questions...sorry)

I'm trying to better understand why 'strict' is safer. I use it all the time and the code I write is usually "safe", but I don't know why it would be unsafe.

Thanks for all your help.

Amel - f.k.a. - kel

[tye]

You create a symbolic reference like this:

$a= "this";

Doesn't look like a symbolic reference, does it? But it is. It isn't the creating of symbolic references that is a problem; it is using symbolic references. You use a symbolic reference just like you use a regular reference. So:

$b= $$a;

is where we have a problem. But it is only a problem if $a doesn't contain a real (non-symbolic) reference. That is why use of symbolic references (and not creation of them) is only caught at run time.

Like I said elsewhere, "unsafe" doesn't make a lot of sense to me in discussing strict.pm. strict.pm helps Perl to catch things that are probably simple programmer mistakes. By catching them explicitly, you usually save time in trying to find the mistake and fix it.

        - tye (but my friends call me "Tye")