Re^4: Use of uninitialized variables?

As far as these variables go, my limits the scope in such a way that in a different module the variable isn't available.

No one's disputing that.

Here's a slightly more concrete usage, and two instances where the issue happens

You're creating instances of a class before the class's module has been executed, and you're blaming the module? Change

...

package Problem;

{
   ...
   1;
}

package Main;

...
[download]

...

BEGIN {
   package Problem;
   ...
}

...
[download]

or move the code to a used file. use adds the BEGIN for you.

(By the way, the "1;" is useless, and you misspelled "package main;". And note how "package main;" is no longer needed when you move the package statement into the curlies.)

As for the second issue,

my $p1 = undef;
BEGIN
{
   $p1 = Problem->new('P11', 'P12', 'P13');
}
[download]

I've already stated I think you're obviously doing something wrong if you're initializing something twice.

Comment on Re^4: Use of uninitialized variables? Select or Download Code

Replies are listed 'Best First'.
Re^5: Use of uninitialized variables? by Glav (Novice) on Jun 12, 2008 at 19:31 UTC
I've already stated I think you're obviously doing something wrong if you're initializing something twice. We're in violent agreement that you shouldn't initialize something twice; this is simply an illustrative example of what happens when you do, as is being recommended to me. It looks like undef or () is being assigned right away, but it's not, depending on how the module is used. The assignment at a later point is supposed to be the initial value, NOT the value on the same line. By assigning early you can cause problems, which is the point of the example above. Initializing these values that you expect to initialize later is a completely superfluous and potentially (as shown in the above example) disastrous process.	[reply]
Re^6: Use of uninitialized variables? by ikegami (Patriarch) on Jun 12, 2008 at 19:57 UTC
as is being recommended to me What the OP quoted wasn't nearly that specific. Keep in mind the goal of an idiom or practice when applying it. In this case, it's for "the readers of the code can immediately see that the lack of definition is intentional". That means that `my $var; BEGIN { $var = ...; }` [download] satisfies the requirements. You can even put those two statements on the same line. I provided an example above of what would satisfy the practice if you had some complex initialization code in a previous post in this thread. You always have to be very careful when using BEGIN blocks to make sure all the code that should be in a BEGIN block is in a BEGIN block. You've shown an example of this already when the inline module that did everything right was messed up by a BEGIN block in its user. Basically, what I'm saying is you can't change `my $var = "some value"; ... code that uses $var ...` [download] to `my $var = "some value"; BEGIN { ... code that uses $var ... }` [download] You need to change it to `my $var; BEGIN { $var = "some value"; ... code that uses $var ... }` [download] If you're particularly "picky", you could use `my $var; BEGIN { $var = "some value"; } BEGIN { ... code that uses for $var ... }` [download] It has nothing to do with whether "some value" is there because PBP recommended it, or because it needs to be there for the code to function. I don't agree with the practice the OP quoted, but badly applying BEGIN blocks is not an argument against the practice.	[reply] [d/l] [select]